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 drop-down menu or add a new Forward Proxy HTTP Listener. To add Forward Proxy HTTP Listeners from this dialog:
|
|---|---|
| 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, select "[All]" from the drop-down 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 select "[All]" from the drop-down 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:
In a situation like that, 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. |
Primary Connection (outgoing) & Secondary Connection (outgoing)
| Service URL | Contains the full URL for the target application (comprising the service host, service port, and forward path). You can enter a complete URL here and/or edit specific components in the associated fields. Updates made in one area will be propagated to the other (for example, if you modify the port in the Service URL field, the value in the Service port field will be updated automatically). |
|---|---|
| Service host | Enter the host name of the machine where the service resides. This is the machine to which the proxy will send messages. If you want the proxy to forward to a virtual asset on the local server without consuming an HTTP connection, enter The Service host may also be set to "[Passthrough]," which will route the request to the original host requested by the client, or "[Virtualize]," which will instead route the request to Virtualize to be handled by a Virtual Asset or Message Proxy. Select either option from the drop-down menu. |
| Service port | Enter the port where the service is listening. This is the port to which the proxy will send messages. |
| Service forward path | (Optional) Enter the path to which the proxy should forward the messages that it receives. If blank, the proxy will forward messages along the original incoming path without modification. If the proxy is sending messages to If the Service 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. |
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.
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 dropdown:
- 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.
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
