I am attempting to implement an HTTP tunnel using similar techniques to those employed by web browsers to simulate a full-duplex connection, in Java using the Netty framework. I wish to implement this in such a way that it will work in the presence of real world HTTP proxies. I am attempting to do this without using a servlet container, to avoid unnecessary overhead in terms of library dependencies, and because the servlet API does not fit the usage patterns of a full duplex http tunnel.
I am aware of some restrictions that HTTP proxies impose that "break" some potential uses of the HTTP protocol:
However there is one additional possibility that I am not sure about: do real world HTTP proxies also share a persistent connection to a server between multiple clients? For instance:
Would the proxy then potentially open a single connection to server X and send messages in the order:
A1, A2, B1, C1, B2, A3, C2, C3
or a similar order that preserves the ordering from each individual client, but potentially interleaved? Or even worse, could the proxy open multiple connections to the server and scatter messages from each client between the connections, i.e.
Connection 1: A1, C1, C2, C3
Connection 2: B1, B2, A2, A3
If so, my approach requires more thought as I potentially need to demultiplex these messages into different queues for each tunnel, and cannot simply rely on identifying a connection as being used for a particular client.
Does anyone know of any good resources that describe the quirks of commonly used HTTP proxies and stateful inspecting firewalls?
The HTTP 1.1 spec contains this paragraph as 8.1.4 Practical Consideration:
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
I don't know what real world proxy implementations do with this requirement, though.
Maybe you'll find something in the Caching Tutorial, even if it's only useful links. The ultimate action might be to send a mail to Mark Nottingham ([email protected]). If he doesn't know, nobody does.