Page History

...

The Service SSL section needs to be completed only if the service you are working with uses SSL.

If the service being virtualized and/or the application under test uses SSL and/or other authentication (basic/digest, Kerberos, NTLM), additional configuration may be required.For details on completing the Service SSL fields immediately below these fields, see Security Configuration.

...

Example: Sending Traffic to a Service

Assume that we want to create a message capture traffic for a service that is normally accessed at http://example.parasoft.com:90808080/BookStore. We could create use the following settings to send traffic to a live service using an HTTP Reverse proxy with the settings: listener:

• Reverse Proxy: 7070 listener
• Proxy listen path: /BookStore[All]
• Primary (Direct): http://Service host: example.parasoft.comService port: 9080
• Service forward path: [empty]
  Image Removed
• 8080

Image Added

This configuration will listen on /BookStore port 7070 and forward all traffic to the actual bookstore service.

If we wanted to listen on a path other than the service path, we would change the configuration of the proxy as follows:

• Service forward path: /BookStore
• Proxy listen path: /SomeOtherPath
  Image Removed

This would route traffic from /SomeOtherPath on the proxy to the actual bookstore service. 

In both cases, all traffic that goes to those paths (including sub paths) is sent to the service. In the second example, traffic sent to /SomeOtherPath/SubPath would be sent to /BookStore/SubPath. Because queries are preserved, /SomeOtherPath?param=value would be sent to /BookStore?param=value.

Forwarding Requests to Services that Require Case-sensitive Header Names

If you are using the desktop's server, your message proxy headers will be lowercased and may fail to function properly when requests are forwarded to a service that requires case-sensitive HTTP header names.

You can create a _global.headers file in the /VirtualAssets/ directory and add the headers using the specific capitalization you want to pass. Right-click the server in the UI and re-deploy all virtual assets to begin using this file in your environment.

Using HTTP listeners is the recommended connection configuration for recording HTTP traffic, as it simplifies updating the client application to point to the Virtualize server’s host and HTTP listener port without requiring any changes to the paths. This applies whether forwarding traffic to a live service or a virtual asset.

If you want to use the default listener, you will need to provide a proxy listen path. For example:

• Reverse Proxy: Default listener
• Proxy listen path: /BookStore
• Primary (Direct): http://example.parasoft.com:8080

Image Added

This configuration will listen on /BookStore and forward all traffic to the actual bookstore service.

If you want to listen on a path other than the service path, you could change the configuration of the proxy as follows:

• Reverse Proxy: Default listener
• Proxy listen path: /proxyPath
• Primary (Direct): http://example.parasoft.com:8080/BookStore

Image Added

This would route traffic from /proxyPath on the proxy to the actual bookstore service.

In both cases, all traffic that goes to those paths (including sub-paths) is sent to the service. In the second example, traffic sent to /proxyPath/SubPath would be sent to /BookStore/SubPath. Because queries are preserved, /proxyPath?param=value would be sent to /BookStore?param=value.

Forwarding Requests to Services that Require Case-sensitive Header Names

If you are using the desktop's server, your message proxy headers will be lowercased and may fail to function properly when requests are forwarded to a service that requires case-sensitive HTTP header names.

You can create a _global.headers file in the /VirtualAssets/ directory and add the headers using the specific capitalization you want to pass. Right-click the server in the UI and re-deploy all virtual assets to begin using this file in your environment.

You can also address HTTP You can also address HTTP header capitalization issues for specific message proxies. Create a <PROXY-NAME>.headers file in the /VirtualAssets/ directory and add the headers using the specific capitalization you want to pass for the specific proxy. This file will apply to specific proxy and override the global file. Right-click the server in the UI and re-deploy all virtual assets to begin using this file in your environment.

...

Example: Sending Traffic to a Virtual Asset

A proxy can also send traffic to a virtual asset. In that case, enter the host and port information for the Virtualize Server as if were just another service.

For example, to send traffic to a virtual asset on a remote server, you might use: 

• Proxy listen path: /proxyPath
• Service host: server.parasoft.com
• Service port: 9080
• Service forward path: /assetPath
  Image Removed

To send traffic to a virtual asset on a local server using an HTTP Listener, you might use:

• Reverse Proxy: 7070
• Service host: [Virtualize]

Image Removed

To send traffic to a virtual asset on a local server without an HTTP Listener, you might use:

• Proxy listen path: /proxyPath
• Service host: [Virtualize]
• Service forward path: /assetPath
  Image Removed

Excerpt Include+
nopanel true scrollPageId 0A010204015AA57234C09FA35DF701DE

The HTTP Reverse proxy makes no distinction between a virtual asset and an actual service. Both are configured the same way. However, if the Default HTTP Reverse proxy (without an HTTP Listener) is sending to [Virtualize] or localhost, you must specify Service forward path because the proxy doesn't allow forwarding to itself.

Info
title Forwarding Requests to Services that Require Case-sensitive Header Names
If you are using the Virtualize desktop's server, your message proxy headers will be lowercased and may fail to function properly when requests are forwarded to a service that requires case-sensitive HTTP header names. See Forwarding Requests to Services that Require Case-sensitive Header Names for details.

...