Forwarding HTTP Requests Inwards
In order to send data to a profile via HTTP/HTTPS, a dedicated URL needs to be used. The schematic structure of the URL is
HTTP(S)://<server and port>/<URL context>/<URL suffix> |
Incoming HTTP requests are handled by the Lobster Integration Server on the DMZ machine. By default, the DMZ reacts to HTTP requests whose URL path begins with the URL context /forward. This default can be overridden in file ./etc/startup_dmz.xml using the parameters servletContext and servletPath (see table in section Parameters).
In the following, we assume that the standard is used, so servletContext and servletPath are not defined. In this case, servletContext=/forward and servletPath=/* are used.
In addition to the context /forward, configuration in ./etc/startup_dmz.xml can also be used to allow further HTTP paths to be forwarded:
URL Context |
Condition 1 |
Condition 2 |
Recommended Forwarding Rule in forward.properties |
/dw/Request |
addStandardServlet=true |
|
/dw/Request/*=http://<inner>/dw/Request |
/dw/trigger |
addStandardServlet=true |
|
/dw/trigger/*=http://<inner>/dw/trigger |
/dw/request |
addStandardServlet=true |
|
/dw/request/*=http://<inner>/dw/Request |
/dw/Trigger |
addStandardServlet=true |
|
/dw/Trigger/*=http://<inner>/dw/trigger |
/partner |
addStandardServlet=true |
handleAS2=false |
/partner/AS2Retrieve/*=http://<inner>/partner/AS2Retrieve |
/forward |
<always> |
|
|
In the table, <inner> is the IP address or the DNS name of the inner Lobster_data, and the port number if applicable. If the HTTPS connector is active on this system, forwarding can also take place via HTTPS. Since the connection from the DMZ to the internal Lobster_data takes place in a protected network part, however, a further encryption by HTTPS is probably not necessary there.
If the DMZ server has multiple connectors (port 80, 443, and so on) within ./etc/hub.xml, all requests that arrive via one of the connectors and correspond to a forward rule are routed according to the rule. On the target system <inner>, it is no longer possible to distinguish whether the original request used the HTTP or HTTPS protocol.
These paths (table) can be used additionally and independently of the path /forward if the specified conditions in the configuration (startup_dmz.xml) are fulfilled. The path /partner/* is not taken over from the HttpForwardServlet for /partner/*, but from the AS2 service on the DMZ system. See also section AS2 on DMZ Server.
The forwarding does not take effect until a corresponding forwarding rule exists for the path or a sub-path. In the forwarding rule, it is not necessary for the entire context to be forwarded, one can also specify individual subpaths. For example, you can control whether all profiles with HTTP agents can receive data via HTTP upload via the DMZ server, or only individual selected profiles. A forwarding rule whose left part does not match one of the specified paths is not effective. The forwarding rules are explained in more detail below using the /forward context.
Forwarding Rules (file ./etc/forward.properties)
Now it needs to be determined whether and, if so, where the incoming HTTP requests are forwarded. For example, requests for a Lobster_data profile are forwarded to the internal server. The configuration for this is done in the file ./etc/forward.properties.
Each line of this file represents an independent rule. The side left to the equals sign (source context), should be unique. A rule only works if there is an active HttpForwardServlet for the source context (see table above).
...
/forward/*=http://www.google.de
/forward/images/*=http://www.google.de/images
/forward/intl/de_ de/images/*=http://www.google.de/intl/de_de/images
/forward/E/*=http://www.lobster.de
...
#Forward to inner Lobster_ data
/forward/example/*=http://192.168.213.80/dw/Request/urlsuffix/example
...
Note: Changes to the file forward.properties are recognised during runtime and are reevaluated. A restart is not necessary. For diagnostic purposes, the HTTP request log and the server log can be evaluated under ./logs. Caution: The times in the request log are in the time zone UTC, the times in the server log are in the system time zone.
The following figure shows examples where incoming HTTP requests are forwarded to using the demonstrated configuration.
Incoming HTTP Request |
Forwarded HTTP Request |
http://www.xyz.com/forward/example |
http://www.google.de/example |
http://www.xyz.com/forward/images/example.jpg |
http://www.google.de/images/example.jpg |
http://www.xyz.com/forward/intl/de_de/images/example.jpg |
http://www.google.de/intl/de_de/images/example.jpg |
http://www.xyz.com/forward/E/index.html |
http://www.lobster.de/index.html |
http://www.xyz.com/forward/example/file.txt |
http://192.168.213.80/dw/Request/urlsuffix/example/file.txt |
http://www.xyz.com/noforward/ |
No forwarding. |
Note: In order to use URL paths with Lobster_data standard contexts
to trigger a profile (default context /dw/trigger/)
for an HTTP request (default context /dw/Request/)
for AS2 receiving (default context /partner/AS2Retrieve/)
, you can set up the CommunicationForwardManager using the entry addStandardServlets in file ./etc/startup_dmz.xml (see section Parameters), see the following listing .
<
Call
name
=
"addApplication"
>
<
Arg
>
<
New
class
=
"com.ebd.hub.datawizard.app.CommunicationForwardManager"
>
...
<!-- Add /dw/Trigger, /dw/Request (as well in lowercase) and /partner servlets on demand -->
<
Call
name
=
"addStandardServlets"
><
Arg
type
=
"boolean"
>True</
Arg
></
Call
>
...
</
New
>
</
Arg
>
</
Call
>
For an inward redirection, file ./etc/forward.properties could contain
/dw/Request/*=http://<inner server and port>/dw/Request
Note: It is possible to ’tunnel’ HTTP(S) requests through the Message Service. To do so, insert the following option into configuration file ./etc/startup.xml on the DMZ server.
<
Set
name
=
"tunnelHttp"
>true</
Set
>
Note: The HttpForwardServlet is also used in HTTP or HTTPS response routes of a profile to send via DMZ. This is independent of the configuration described here.