Ignore:
Timestamp:
Jul 1, 2011, 9:56:52 AM (8 years ago)
Author:
julian.reschke@…
Message:

add guidance on minimum sizes of protocol elements (see #282)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1321 r1323  
    3636  <!ENTITY status-203             "<xref target='Part2' x:rel='#status.203' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3737  <!ENTITY status-3xx             "<xref target='Part2' x:rel='#status.3xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     38  <!ENTITY status-4xx             "<xref target='Part2' x:rel='#status.4xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3839  <!ENTITY status-414             "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3940]>
     
    13641365   (i.e., other than the backslash octet "\" and the parentheses "(" and
    13651366   ")").
     1367</t>
     1368<t>
     1369   HTTP does not place a pre-defined limit on the length of header fields,
     1370   either in isolation or as a set. A server &MUST; be prepared to receive
     1371   request header fields of unbounded length and respond with a 4xx status
     1372   code if the received header field(s) would be longer than the server wishes
     1373   to handle.
     1374</t>
     1375<t>
     1376   A client that receives response headers that are longer than it wishes to
     1377   handle can only treat it as a server error.
     1378</t>
     1379<t>
     1380   Various ad-hoc limitations on header length are found in practice. It is
     1381   &RECOMMENDED; that all HTTP senders and recipients support messages whose
     1382   combined header fields have 4000 or more octets.
    13661383</t>
    13671384</section>
     
    40494066</section>
    40504067
     4068<section title="Protocol Element Size Overflows" anchor="attack.protocol.element.size.overflows">
     4069<t>
     4070   Because HTTP uses mostly textual, character-delimited fields, attackers can
     4071   overflow buffers in implementations, and/or perform a Denial of Service
     4072   against implementations that accept fields with unlimited lengths.
     4073</t>
     4074<t>
     4075   To promote interoperability, this specification makes specific
     4076   recommendations for size limits on request-targets (<xref target="request-target"/>)
     4077   and blocks of header fields (<xref target="header.fields"/>). These are
     4078   minimum recommendations, chosen to be supportable even by implementations
     4079   with limited resources; it is expected that most implementations will choose
     4080   substantially higher limits.
     4081</t>
     4082<t>
     4083   This specification also provides a way for servers to reject messages that
     4084   have request-targets that are too long (&status-414;) or request entities
     4085   that are too large (&status-4xx;).
     4086</t>
     4087<t>
     4088   Other fields (including but not limited to request methods, response status
     4089   phrases, header field-names, and body chunks) &SHOULD; be limited by
     4090   implementations carefully, so as to not impede interoperability.
     4091</t>
     4092</section>
     4093
    40514094<section title="Denial of Service Attacks on Proxies" anchor="attack.DoS">
    40524095<t>
     
    59225965    </t>
    59235966    <t>
     5967      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/282"/>:
     5968      "Recommend minimum sizes for protocol elements"
     5969    </t>
     5970    <t>
    59245971      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/283"/>:
    59255972      "Set expectations around buffering"
Note: See TracChangeset for help on using the changeset viewer.