HTTP support in MQIPT

MQIPT supports HTTP tunneling. MQIPT can be configured so that the data packets it forwards are encoded as HTTP requests.

IBM® MQ channels do not accept HTTP requests. Therefore a second MQIPT is required to receive the HTTP requests and convert them back into IBM MQ protocol packets. The second MQIPT removes the HTTP header to convert the incoming packet back into a standard IBM MQ protocol packet, before passing it on to the destination queue manager.

When HTTP is being used between two instances of MQIPT, the TCP/IP connection on which the HTTP requests and replies flow is persistent and is kept open for the lifetime of the message channel. MQIPT does not close the TCP/IP connection between request/reply pairs.

If two instances of MQIPT are communicating through HTTP, it is possible that an HTTP request might stay outstanding for an extended period. An example is in a requester/server channel, when the server side is waiting for new messages to arrive on its transmission queue. The IBM MQ channel protocol provides a "heartbeat" mechanism, which requires the waiting end periodically to send heartbeat messages to its partner. The default channel heartbeat period is 5 minutes. MQIPT uses this heartbeat as the HTTP reply. Do not disable this channel heartbeat, or set it to an excessively high value, to avoid causing problems with timeouts in some firewalls.

MQIPT accepts HTTP traffic in chunked format, generated by an HTTP proxy or server.

For an example of using HTTP in MQIPT, see Configuring HTTP tunneling.

HTTP proxies

A HTTP proxy can be placed in between the two instances of MQIPT. The HTTP proxy must meet the following requirements:
  • The proxy must support the HTTP 1.1 protocol.
  • The Connection or Proxy-Connection HTTP headers that are set by MQIPT must be honored by the proxy. This allows connections between the two instances of MQIPT to be kept open for the lifetime of the message channel.
  • A one-to-one mapping of persistent connections must be maintained across the proxy. This ensures that TCP/IP connections from the proxy to the destination MQIPT are not used to transmit data for more than one message channel.
You can set properties to configure how persistent connections are managed on some HTTP proxies. For example, you might be able to set the maximum number of requests that can be made on a persistent connection. The following properties should be set:
  • Persistent connections should enabled.
  • The reuse of TCP/IP connections from the proxy to MQIPT by more than one HTTP session should be disabled, to maintain a one-to-one mapping of persistent connections across the proxy.
  • The timeout on proxy requests should be set to a high value. For example, 12 hours.
  • The maximum number of requests that can be made on a persistent connection should be set to a high value. For example, 5000.

MQIPT uses HTTP POST requests to send data between the two instances of MQIPT. If the MQIPT configuration specifies the hostname of the proxy using the HTTPProxy property, MQIPT connects to the proxy and uses the HTTP CONNECT method to request that the proxy establish a tunnel to the destination MQIPT. This allows HTTPS connections to pass through the proxy without terminating the TLS session in the proxy.

If a load balancer is placed between the MQIPT instances, it must be configured to use the value of the MQIPTSessionId HTTP cookie to ensure that all requests for each session are forwarded to the same destination.