W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

#282: Recommend minimum sizes for protocol elements

From: Mark Nottingham <Mnot@mnot.net>
Date: Mon, 2 May 2011 11:46:42 +1000
Message-Id: <103AF63F-5E11-4FC4-8FE7-6D04C6FEF8B0@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>

We talked about this briefly in Prague. Since then I've put together a straw-man proposal:

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 headers have 20,000 or more octets.

Add section to p1 Security Considerations:

> 11.5 Protocol Element Size Overflows
> Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform a Denial of Service against implementations that accept fields with unlimited lengths.
> To promote interoperability, this specification makes specific recommendations for size limits on request-targets [ref] and blocks of header fields [ref]. These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected that most implementations will choose substantially higher limits.
> This specification also provides a way for servers to reject messages that have request-targets that are too long [ref] or request entities that are too large [ref].
> Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) SHOULD be limited by implementations carefully, so as to not impede interoperability.

Thoughts? We can go further than this, of course, but IME request-target and headers are the big ones.


Mark Nottingham   http://www.mnot.net/
Received on Monday, 2 May 2011 01:47:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:51 UTC