java - HTTP 1.1 Pipelining

Question

I have to implement an HTTP client in Java and for my needs it seems that the most efficient way to do it, is implement HTTP pipeline (as per RFC2616).

As an aside, I want to pipeline POSTs. (Also I am not talking about multiplexing. I am talking about pipelining i.e. many requests over one connection before receiving any response- batching of HTTP requests)

I could not find a third party library that explicitly states it supports pipelining. But I could use e.g. Apache HTTPCore to build such a client, or if I have to, build it by myself.

The problem I have is if it is a good idea. I have not found any authoritative references that HTTP pipelining is something more than a theoretical model and is properly implemented by HTTP servers. Additionally all browsers that support pipelining have this feature off by default.

So, should I try to implement such a client or I will be in a lot of trouble due to server's implementations (or proxies). Is there any reference that gives guidelines on these?

If it is a bad idea what would be the alternative programming model for efficiency? Separate TCP connections?

Answer 1

POST should not be pipelined

8.1.2.2 Pipelining

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.

Clients which assume persistent connections and pipeline immediately after connection establishment SHOULD be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it MUST NOT pipeline before it knows the connection is persistent. Clients MUST also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.

Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html