[Mongrel] HTTP Pipelining

Dan Kubb dan.kubb at autopilotmarketing.com
Tue Aug 8 00:12:33 EDT 2006

Hash: SHA1

Hi Zed,

> 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
this helps.

> 4) Who closes?  It's not clear if the client closes, the server  
> closes,
> 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  
> it's
> hidden in little SHOULD and MAY statements in all sorts of irrelevant
> sections.


    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).  
Confirmation by
    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  
    is suspected.

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 [45]  
    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  
might be
    contained therein.

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  
> request?


    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

- --



Dan Kubb
Autopilot Marketing Inc.

Email: dan.kubb at autopilotmarketing.com
Phone: 1 (604) 820-0212
Web:   http://autopilotmarketing.com/
vCard: http://autopilotmarketing.com/~dan.kubb/vcard

Version: GnuPG v1.4.2.2 (Darwin)


More information about the Mongrel-users mailing list