Re: #282: Recommend minimum sizes for protocol elements

On Sun, Jun 26, 2011 at 12:03 AM, Mark Nottingham <mnot@mnot.net> wrote:
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/282>
>
> Revised proposal:
>
>
> For HTTP headers, insert at end of p1 3.2:
>
> """
> HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server MUST be prepared to receive request headers of unbounded length and respond with the 413 (Request Entity Too Large) status code if the received header(s) would be longer than the server wishes to handle (see Section 8.4.14 of [Part2]).
>
> A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.
>
> Various ad-hoc limitations on header length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support messages whose combined header block (i.e., from the start of the request-line or response-line until the CRLF CLRF that terminates the headers) have 4,000 or more octets.
> """

This looks good.  The language currently in Section 8.4.14 allows the
server to send the 413 and drop the connection as soon as it sees the
4001st byte of the request header, thus thwarting malicious clients
who try to keep the server busy by sending an infinite stream of
headers.

In the case of HTTP requests arriving via SPDY, short-circuiting the
413 response will be a little more complicated: in order to keep the
server's session-scoped gzip state from falling out of sync with the
client, the server will have to either: 1) send the entirety of the
request headers through its gzip engine before discarding them or 2)
drop the entire session, rather than just the affected stream, when it
sends the 413, and thus drop any other requests that might have been
in line behind the too-large request.  I don't see any good way to
solve this in the HTTP spec, though; it's really an inherent tradeoff
between efficiency (session-scoped compression state) and resiliency
(request/stream-scoped compression state) at a lower layer.

-Brian

Received on Sunday, 26 June 2011 13:38:39 UTC