This topic explains how to configure message proxies that send and receive messages over an HTTP Proxy that routes traffic based on the “Host” header. HTTP Forward proxies are best used with Mobile applications where the backend service endpoint is not configurable or in applications under test when there is no configuration option available to change the host and port used to connect to a backend service.

In this section: 

Connection Settings

To specify HTTP Forward proxy connection options, set the following service and listening details.

Proxy Settings (incoming) 

These settings specify where messages from the client should connect in order to communicate with the application under test:

Forward proxy: You can choose a Forward Proxy HTTP Listener that you defined when creating the proxy (see Creating Proxies) from the menu or add a new Forward Proxy HTTP Listener. To add Forward Proxy HTTP Listeners from this dialog:

  1. Click New.
  2. Specify a name and port for the listener.
  3. Click OK.

Host: Enter the host name of the service whose traffic you want to monitor. This determines which hosts are recorded, sent to the live service, or sent to a virtual asset. To allow monitoring for all traffic, choose [All] from the menu.

Path: Enter a path that you want to monitor on the resource. This works in conjunction with what has been entered in the Host field to match incoming requests. Wild cards are not allowed. To match all paths on the host, leave this field blank or choose [All] from the menu.

In the event that there are multiple proxy connections configured that could match to an incoming request, the one with the combination of best host match and longest matching path is selected, with the host match being the more heavily weighted factor. For example, suppose there was an incoming target URL of https://parabank.parasoft.com/parabank/services/bank/customers/12212 and four proxies that could match to it:

  1. Host: parabank
    Path: /parabank
  2. Host: parabank.parasoft
    Path: /parabank/services/bank/customers
  3. Host: parabank.parasoft.com
    Path: /parabank/services_proxy
  4. Host: parabank.parasoft.com
    Path: /parabank/services

In such a situation, proxy #4 would be selected because, even though #2 has the more exact Path match, #4 has the better Host match and, unlike #3, at least a partial Path match.

Service Connection (outgoing)

Specify the URL or path to a Virtual Asset or Message Proxy for the target application for both the primary and secondary connections. You can also choose to route the request to the original host requested by the client. Primary and Secondary are set up the same way:

  • To specify the URL for the target application: choose Custom from the menu and enter the full URL, comprising of the service host, service port, and (optionally) forward path in the URL field. See the notes below regarding each of these components of the service URL. Note that query parameters will be ignored if specified in the URL field.
    • Service host: If you want the proxy to forward to a virtual asset on the local server without consuming an HTTP connection, enter host.virt.internal, localhost, or 127.0.0.1 as the service host rather than the actual hostname. When using localhost or 127.0.0.1, the service port must match the port Virtualize is deployed on; when using host.virt.internal the service port is not used. For example, a virtual asset deployed on http://localhost:9080/myVirtualAsset can also be reached using http://host.virt.internal/myVirtualAsset.
    • Service port: This is the port to which the proxy will send messages.
    • Forward path: If no forward path is specified, the Proxy listen path is used. If the HTTP proxy is sending messages to localhost, you must specify a forward path because the proxy doesn't allow forwarding to itself. If the forward path sends a redirect, the proxy will follow the redirect and then respond back. It will not pass the redirect back to the client. See Service Forward Path and Proxy Listen Path for more details.
  • To specify the path to a Virtual Asset or Message Proxy for the target application: choose Virtualize from the menu and enter the path to the Virtual Asset or Message Proxy in the Path field.
  • To route the request to the original host requested by the client, choose Passthrough from the menu.

Options

Mode: Allows you to set the active forwarding connection when a primary and secondary connection exist. For example, during a recording session, a message proxy may forward to the live service as the primary connection and fall back to a virtual service as a secondary connection. In this case, you can set the HTTP mode to Primary and enable Use other connection if selected mode fails.

Once recording is complete and new virtual assets are generated, you may want to re-configure the proxy to forward to the virtual service first and fall back to the live service if a failure occurs. This change can be quickly applied by right-clicking the proxy and switching the HTTP mode to "secondary". The failover will be adjusted accordingly at runtime.

Use other connection if selected mode fails: Enable this option if you want traffic to be redirected to the backup proxy endpoint when the active connection (as determined by the Mode selected above) fails. The connection will be considered "failed" if the response status code is 400 level or higher.

Bypassing proxy failover

Message Responders can be configured to bypass this proxy failover for internally routed messages by enabling Skip message proxy failover.

If this option is not enabled, the active connection will be used for recording.

If this option is enabled, select a recording option from the Record menu:

  • Both connections: Records traffic for both the primary and secondary connections. Error messages from the active connection will not be recorded; instead, the messages will be sent to the backup connection and the responses will be recorded. Errors reported by the backup will be recorded.
  • Primary connection only: Records traffic for the active connection. Does not record errors.
  • Secondary connection only: Records traffic for the backup connection, including errors.

Valid HTTP response code ranges: Allows you to customize the message proxy's failover behavior so that it succeeds with HTTP response codes outside the 2xx range. Specify single codes and/or code ranges as a comma-separated list. For example, if you use "404, 500-599", a 404 code or any code in the 5xx range will be accepted.

Learn responses: Enable this option if you want your internal endpoint to learn to emulate the responses recorded from a live endpoint. The internal endpoint must have a files responder (see Request/Response Files for more information). This option is only available when Use other connection if selected mode fails is enabled (see above). You can easily enable/disable learning by the proxy by right-clicking the proxy and switching the mode to Enable All or Disable All.

Example: Sending Traffic to a Service

Assume that we want to create a message for a service that is normally accessed at http://parabank.parasoft.com. We could create an HTTP Forward proxy with the settings: 

  • Host: parabank.parasoft.com
  • Service host: [Passthrough]

This configuration will watch for traffic sent to host parabank.parasoft.com and pass traffic to the live service as usual.

If we wanted to redirect traffic to a different service host and port, we could change the configuration of the proxy as follows:

  • Service host: coyote.parasoft.com
  • Service port: 8080
  • Service forward path: [empty]  

This will route traffic intended for parabank.parasoft.com to a different service on coyote.parasoft.com:8080.

Example: Sending Traffic to a Virtual Asset

A proxy can also send traffic to a virtual asset. By using a local virtual host like host.virt.internal or the built-in "[Virtualize]" option as the Service host, we can forward to a virtual asset on the local server without consuming an HTTP connection (see Primary Connection (outgoing) & Secondary Connection (outgoing) above for more information).

One way to do this is to change the primary outgoing connection to host.virt.internal to send traffic to a virtual asset on a local server: 

  • Service host: host.virt.internal
  • Service port: 9080
  • Service forward path: /path

Alternatively, since the secondary connection is configured to point to a local virtual asset by default, another option would be to simply change the Mode from Primary to Secondary. 

  • Service host: [Virtualize]
  • Service forward path: /path
  • Mode: Secondary

Installing the Parasoft Root Certificate Authority

Before you can use an HTTP forward proxy on a mobile emulator, the Parasoft Root Certificate Authority must be installed as a trusted certificate. If the certificate authority is not installed, the browser will not consider the connection secure and may refuse to allow the connection.

Android Emulator

iOS Emulator

Android Emulator

This procedure assumes that you are using Android Studio/Android Sdk and that you have created an Android Virtual Device (AVD) on a non-production build. Additionally:

Because CA certificates in Android are stored by their hashed name with the file extension .0, you will need to copy and rename the Parasoft certificate. To do that, open a command prompt and navigate to <VIRT-INSTALL-DIR>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/lib then run the following command:

hashed_name=`openssl x509 -inform PEM -subject_hash_old -in parasoft.cer | head -1` && cp parasoft.cer $hashed_name.0

You need to place the hash.0 version of the CA certificate in the system certificate store in the Android filesystem, found at /system/etc/security/cacerts/. The /system partition is mounted as read-only by default, however, so you will first need to change permissions to it. Exactly how you do that depends on what version of the emulator you are using.

API Level 29 or higher

Starting with API Level 29, you can't mount the "/" partition with read-write permissions normally. Google has provided a workaround (see https://android.googlesource.com/platform/system/core/+/master/fs_mgr/README.overlayfs.md for more information), but some users find that this results in their emulator getting stuck in a boot loop. If that's the case, you can try the workaround detailed below:

You have to start the emulator using the -writable-system option in order to use the certificate, otherwise Android will load a “clean” system image.

  1. Start your AVD:

    emulator -avd <AVD_NAME> -writable-system
    • If you're not sure of the name of your AVD, run emulator -list-avds to pull up a list of all your AVDs.

  2. Restart adb as root:

    adb root

  3. Disable secure boot verification: 

    adb shell avbctl disable-verification

  4. Reboot the device and restart adb as root: 

    adb reboot
adb root

  5. Remount the partitions as read-write: 

    adb remount

    • If adb indicates that you need to reboot, run adb reboot and adb remount again.

  6. Push the hash.0 version of the certificate: 

    adb push <PATH_TO_CERT> /system/etc/security/cacerts

  7. Set certificate permissions: 

    adb shell chmod 664 /system/etc/security/cacerts/<NAME_OF_HASH.0_CERT>

  8. Reboot the device again: 

    adb reboot

API Level 28 or less

You have to start the emulator using the -writable-system option in order to use the certificate, otherwise Android will load a “clean” system image.

  1. Start your AVD:

    emulator -avd <AVD_NAME> -writable-system
    • If you're not sure of the name of your AVD, run emulator -list-avds to pull up a list of all your AVDs.

  2. Restart adb as root:

    adb root

  3. Remount the partitions as read-write: 

    adb remount

    • If adb indicates that you need to reboot, run adb reboot and adb remount again.

  4. Push the hash.0 version of the certificate: 

    adb push <PATH_TO_CERT> /system/etc/security/cacerts

  5. Set certificate permissions: 

    adb shell chmod 664 /system/etc/security/cacerts/<NAME_OF_HASH.0_CERT>

  6. Reboot the device again: 

    adb reboot

iOS Emulator

  1. Host the parasoft.cer file on a file server or email parasoft.cer to an address the iOS emulator can receive. You will find parasoft.cer in <VIRT_INSTALL_DIR>/plugins/com.parasoft.ptest.libs.web_<version>/root/lib.
  2. Open a browser to the URL of the parasoft.cer file or open the email and follow the dialog prompts and accept the configuration profile.
  3. Go to Settings > General > Device Management and choose Parasoft Root Certificate Authority. Click through the installation dialogs leaving the default settings in place.

On recent iOS versions, you also need to enable full trust for the Parasoft Root Certificate. To do so:

  1. Go to Settings > General > About > Certificate Trust Settings.
  2. Under Enable full trust for root certificates, turn on trust for the Parasoft Certificate.


  • No labels

Need assistance? Visit our support page