Interchange 5.12 Administrator Guide Save PDF Selected topic Selected topic and subtopics All content HTTP (embedded) business cases This topic provides examples of using various remote URL and proxy settings to achieve different results with the embedded HTTP transport servers. These business cases apply to the global and community embedded HTTP transport servers. Interchange user interface provides flexibility for several setup variations. The use cases include the most common combinations. Case A Embedded HTTP A partner connects to host:port from a remote URL and sends a POST request containing the path part of the URL. UI settings Field Sample setting Local URL http://server1.domain.com:4080/exchange/routingID Remote URL (same) Proxy (none) Results Action Value Server binds to < cluster_machines>:4080 Partner connects to server1.domain.com:4080 Partner request POST /exchange/routingID HTTP/1.1 HOST server1.domain.com:4080 <other headers and payload> Case B Embedded HTTP with remote URL A partner connects to host:port from a remote URL and sends a POST request containing the path part of the remote URL. The firewall or reverse proxy maps the remote host and port to a real server. In the following example, edi.domain.com:5080 would be mapped to a server in the cluster listening to port 4080. UI settings Field Sample setting Local URL http://server1.domain.com:4080/exchange/routingID Remote URL http://edi.domain.com:5080/exchange/routingID Proxy (none) Results Action Value Server binds to < cluster_machines>:4080 Partner connects to edi.domain.com:5080 Partner request POST /exchange/routingID HTTP/1.1 HOST edi.domain.com:5080 <other headers and payload> Case C Embedded HTTP with remote URL including path remapping This case is the same as the previous case, except that the remote URL has a different path than the local one, which means a proxy is present that is rewriting the path in the POST request based on an internal mapping. In the following example, the path is changed from /inbound/stuff to /exchange/routingID. UI settings Field Sample setting Local URL http://server1.domain.com:4080/exchange/routingID Remote URL http://edi.domain.com:5080/inbound/stuff Proxy (none) Results Action Value Server binds to < cluster_machines>:4080 Partner connects to edi.domain.com:5080 Partner request POST / exchange/routingID HTTP/1.1 HOST edi.domain.com:5080 <other headers and payload> Case D Embedded HTTP with proxy and remote URL including path remapping This case is similar to the previous case, except the host and port of the proxy are explicitly specified. The partner connects to the proxy host:port and sends a POST request containing the full remote URL. The proxy uses this information to establish a connection to the real endpoint server. In the following example, the proxy sends the POST request for edi.domain.com:5080 to one of the servers in the cluster listening to port 4080. It also translates the external /inbound/stuff path to /exchange/routingID. UI settings Field Sample setting Local URL http://server1.domain.com:4080/exchange/routingID Remote URL http://edi.domain.com:5080/inbound/stuff Proxy proxy.domain.com:8080 Results Action Value Server binds to < cluster_machines>:4080 Partner connects to proxy.domain.com:8080 Partner request POST http://edi.domain.com:5080/inbound/stuff HTTP/1.1 HOST edi.domain.com:5080 <other headers and payload> Case E Embedded HTTPS (SSL) with remote URL A partner connects to host:port from remote URL and sends POST request containing the path part of the remote URL. The firewall or reverse proxy maps the remote host and port to a real server. In the following example, edi.domain.com:1453 is mapped to a server in the cluster listening to port 1443. This example does not show path remapping, though that might be present as well. UI settings Field Sample setting Local URL https://server1.domain.com:1443/exchange/routingID Remote URL https://edi.domain.com:1453/exchange/routingID Proxy (none) Results Action Value Server binds to < cluster_machines>:1443 Partner connects to edi.domain.com:1453 Partner request POST /exchange/routingID HTTP/1.1 HOST edi.domain.com:1453 <other headers and payload> Case F Embedded HTTPS (SSL) with proxy and remote URL including path remapping This is similar to the non-HTTPS proxy case, except that the partner starts off by sending a CONNECT request to tell the proxy to establish a tunnel to the endpoint server. This allows it to perform SSL handshaking with the endpoint server before sending the POST request. Note in the following example that the POST request contains only the path, unlike the non-SSL proxy case, which includes the full URL in order to tell the proxy how to find the endpoint server. HTTPS-capable clients that can handle non-transparent proxies are set up to perform these two steps (CONNECT followed by POST), which keeps the setup simpler for the user. UI settings Field Sample setting Local URL https://server1.domain.com:1443/exchange/routingID Remote URL https://edi.domain.com:1453/exchange/routingID Proxy proxy.domain.com:8083 Results Action Value Server binds to < cluster_machines>:1443 Partner connects to proxy.domain.com:8083 Partner request 1 CONNECT edi.domain.com:1453 Partner request 2 POST /exchange/routingID HTTP/1.1 HOST edi.domain.com:1453 <other headers and payload> Related topics Embedded transport servers Types of embedded servers Usage summary of embedded servers Manage embedded servers Global embedded HTTP server Lockout settings for cXML (embedded HTTP) users Modify a global embedded SMTP server Global embedded Web Services API server User interface embedded servers HTTP (embedded) fields FTP (embedded) fields Lockout settings for FTP (embedded) server users SFTP (embedded) server fields Lockout settings for SFTP (embedded) users SMTP (embedded) configuration OFTP (embedded) fields OFTP X.25 over ISDN (embedded) fields PeSIT (embedded) fields Related Links
HTTP (embedded) business cases This topic provides examples of using various remote URL and proxy settings to achieve different results with the embedded HTTP transport servers. These business cases apply to the global and community embedded HTTP transport servers. Interchange user interface provides flexibility for several setup variations. The use cases include the most common combinations. Case A Embedded HTTP A partner connects to host:port from a remote URL and sends a POST request containing the path part of the URL. UI settings Field Sample setting Local URL http://server1.domain.com:4080/exchange/routingID Remote URL (same) Proxy (none) Results Action Value Server binds to < cluster_machines>:4080 Partner connects to server1.domain.com:4080 Partner request POST /exchange/routingID HTTP/1.1 HOST server1.domain.com:4080 <other headers and payload> Case B Embedded HTTP with remote URL A partner connects to host:port from a remote URL and sends a POST request containing the path part of the remote URL. The firewall or reverse proxy maps the remote host and port to a real server. In the following example, edi.domain.com:5080 would be mapped to a server in the cluster listening to port 4080. UI settings Field Sample setting Local URL http://server1.domain.com:4080/exchange/routingID Remote URL http://edi.domain.com:5080/exchange/routingID Proxy (none) Results Action Value Server binds to < cluster_machines>:4080 Partner connects to edi.domain.com:5080 Partner request POST /exchange/routingID HTTP/1.1 HOST edi.domain.com:5080 <other headers and payload> Case C Embedded HTTP with remote URL including path remapping This case is the same as the previous case, except that the remote URL has a different path than the local one, which means a proxy is present that is rewriting the path in the POST request based on an internal mapping. In the following example, the path is changed from /inbound/stuff to /exchange/routingID. UI settings Field Sample setting Local URL http://server1.domain.com:4080/exchange/routingID Remote URL http://edi.domain.com:5080/inbound/stuff Proxy (none) Results Action Value Server binds to < cluster_machines>:4080 Partner connects to edi.domain.com:5080 Partner request POST / exchange/routingID HTTP/1.1 HOST edi.domain.com:5080 <other headers and payload> Case D Embedded HTTP with proxy and remote URL including path remapping This case is similar to the previous case, except the host and port of the proxy are explicitly specified. The partner connects to the proxy host:port and sends a POST request containing the full remote URL. The proxy uses this information to establish a connection to the real endpoint server. In the following example, the proxy sends the POST request for edi.domain.com:5080 to one of the servers in the cluster listening to port 4080. It also translates the external /inbound/stuff path to /exchange/routingID. UI settings Field Sample setting Local URL http://server1.domain.com:4080/exchange/routingID Remote URL http://edi.domain.com:5080/inbound/stuff Proxy proxy.domain.com:8080 Results Action Value Server binds to < cluster_machines>:4080 Partner connects to proxy.domain.com:8080 Partner request POST http://edi.domain.com:5080/inbound/stuff HTTP/1.1 HOST edi.domain.com:5080 <other headers and payload> Case E Embedded HTTPS (SSL) with remote URL A partner connects to host:port from remote URL and sends POST request containing the path part of the remote URL. The firewall or reverse proxy maps the remote host and port to a real server. In the following example, edi.domain.com:1453 is mapped to a server in the cluster listening to port 1443. This example does not show path remapping, though that might be present as well. UI settings Field Sample setting Local URL https://server1.domain.com:1443/exchange/routingID Remote URL https://edi.domain.com:1453/exchange/routingID Proxy (none) Results Action Value Server binds to < cluster_machines>:1443 Partner connects to edi.domain.com:1453 Partner request POST /exchange/routingID HTTP/1.1 HOST edi.domain.com:1453 <other headers and payload> Case F Embedded HTTPS (SSL) with proxy and remote URL including path remapping This is similar to the non-HTTPS proxy case, except that the partner starts off by sending a CONNECT request to tell the proxy to establish a tunnel to the endpoint server. This allows it to perform SSL handshaking with the endpoint server before sending the POST request. Note in the following example that the POST request contains only the path, unlike the non-SSL proxy case, which includes the full URL in order to tell the proxy how to find the endpoint server. HTTPS-capable clients that can handle non-transparent proxies are set up to perform these two steps (CONNECT followed by POST), which keeps the setup simpler for the user. UI settings Field Sample setting Local URL https://server1.domain.com:1443/exchange/routingID Remote URL https://edi.domain.com:1453/exchange/routingID Proxy proxy.domain.com:8083 Results Action Value Server binds to < cluster_machines>:1443 Partner connects to proxy.domain.com:8083 Partner request 1 CONNECT edi.domain.com:1453 Partner request 2 POST /exchange/routingID HTTP/1.1 HOST edi.domain.com:1453 <other headers and payload> Related topics Embedded transport servers Types of embedded servers Usage summary of embedded servers Manage embedded servers Global embedded HTTP server Lockout settings for cXML (embedded HTTP) users Modify a global embedded SMTP server Global embedded Web Services API server User interface embedded servers HTTP (embedded) fields FTP (embedded) fields Lockout settings for FTP (embedded) server users SFTP (embedded) server fields Lockout settings for SFTP (embedded) users SMTP (embedded) configuration OFTP (embedded) fields OFTP X.25 over ISDN (embedded) fields PeSIT (embedded) fields