[Mongrel] HTTP Pipelining
dan.kubb at autopilotmarketing.com
Tue Aug 8 00:12:33 EDT 2006
-----BEGIN PGP SIGNED MESSAGE-----
> But, if you're reading through the spec you might be able to help me
> out, since I'm writing a test suite for this very purpose (and then
> exploits around it). If you can, help me find the answers to these:
I don't know very many of the answers to your questions since I've
never implemented the pipelining part of an HTTP server before. Here's
what I could find for a few of your questions from RFC 2616. Hope
> 4) Who closes? It's not clear if the client closes, the server
> who's allowed to close, when, what situations. This is really unclear
> but incredibly important in a TCP/IP protocol, and in the HTTP RFC
> hidden in little SHOULD and MAY statements in all sorts of irrelevant
When a client or server wishes to time-out it SHOULD issue a
close on the transport connection. Clients and servers SHOULD both
constantly watch for the other side of the transport close, and
respond to it as appropriate. If a client or server does not detect
the other side's close promptly it could cause unnecessary resource
drain on the network.
A client, server, or proxy MAY close the transport connection at any
time. For example, a client might have started to send a new request
at the same time that the server has decided to close the "idle"
connection. From the server's point of view, the connection is being
closed while it was idle, but from the client's point of view, a
request is in progress.
This means that clients, servers, and proxies MUST be able to
from asynchronous close events. Client software SHOULD reopen the
transport connection and retransmit the aborted sequence of requests
without user interaction so long as the request sequence is
idempotent (see section 9.1.2). Non-idempotent methods or sequences
MUST NOT be automatically retried, although user agents MAY offer a
human operator the choice of retrying the request(s).
user-agent software with semantic understanding of the application
MAY substitute for user confirmation. The automatic retry SHOULD NOT
be repeated if the second sequence of requests fails.
Servers SHOULD always respond to at least one request per
if at all possible. Servers SHOULD NOT close a connection in the
middle of transmitting a response, unless a network or client
Not completely clear, but gives a hint anyway. Hmm, is this one of
those "irrelevant sections" you were talking about? ;-)
> 5) What are the official size limits of each element of HTTP? Can
> someone send a 1M header element?
Header lengths? Actually I didn't see a direct reference, but there
a hint in a round-about sort of way here:
HTTP implementations which share code with MHTML 
need to be aware of MIME line length limitations. Since HTTP does
have this limitation, HTTP does not fold long lines. MHTML messages
being transported by HTTP follow all conventions of MHTML, including
line length limitations and folding, canonicalization, etc., since
HTTP transports all message-bodies as payload (see section 3.7.2)
does not interpret the content or any MIME header lines that
The key phrase being "implementations need to be aware of MIME line
limitations. Since HTTP does not have this limitation" leads me to
they do not define any limit on header lengths.
Actually the HTTP spec doesn't limit anything as far as I can tell.
> 7) What's the allowed time limit for a client to complete it's
Servers will usually have some time-out value beyond which they will
no longer maintain an inactive connection. Proxy servers might make
this a higher value since it is likely that the client will be
more connections through the same server. The use of persistent
connections places no requirements on the length (or existence) of
this time-out for either the client or the server.
> 8) Are pipelined requests all sent at once, and then all processed at
> once? Or, are they sent/processed/sent/processed in keeping with HTTP
> request/response semantics.
Pipelining allows a client to make multiple requests without
waiting for each response, allowing a single TCP connection to
be used much more efficiently, with much lower elapsed time.
A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each
Autopilot Marketing Inc.
Email: dan.kubb at autopilotmarketing.com
Phone: 1 (604) 820-0212
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v188.8.131.52 (Darwin)
-----END PGP SIGNATURE-----
More information about the Mongrel-users