Ticket #282: 282.diff

File 282.diff, 6.2 KB (added by julian.reschke@…, 9 years ago)

proposed patch for p1 and p6

  • p1-messaging.xml

     
    3535  <!ENTITY status-1xx             "<xref target='Part2' x:rel='#status.1xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    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-413             "<xref target='Part2' x:rel='#status.413' 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]>
    4041<?rfc toc="yes" ?>
     
    13641365   (i.e., other than the backslash octet "\" and the parentheses "(" and
    13651366   ")").
    13661367</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 the 413 (Request
     1372   Entity Too Large) status code if the received header field(s) would be longer
     1373   than the server wishes to handle (see &status-413;).
     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.
     1383</t>
    13671384</section>
    13681385
    13691386<section title="Message Body" anchor="message.body">
     
    40484065</t>
    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-413;).
     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>
    40534096   They exist. They are hard to defend against. Research continues.
     
    59215964      "HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT"
    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"
    59265973    </t>
  • p6-cache.xml

     
    440440  <x:ref>uri-host</x:ref>      = &lt;uri-host, defined in &uri;&gt;
    441441</artwork></figure>
    442442</section>
     443</section>
    443444
     445<section title="Delta Seconds" anchor="delta-seconds">
     446<t>
     447   The delta-seconds rule specifies a non-negative integer, representing time
     448   in seconds.
     449</t>
     450<figure><artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="delta-seconds" />
     451  <x:ref>delta-seconds</x:ref>  = 1*<x:ref>DIGIT</x:ref>
     452</artwork></figure>
     453<t>
     454   If an implementation receives a delta-seconds value larger than the largest
     455   positive integer it can represent, or if any of its subsequent calculations
     456   overflows, it &MUST; consider the value to be 2147483648 (2<x:sup>31</x:sup>).
     457   Recipients parsing a delta-seconds value &SHOULD; use an arithmetic type of
     458   at least 31 bits of range, and senders &MUST-NOT; send delta-seconds with a
     459   value greater than 2147483648.
     460</t>
    444461</section>
     462
    445463</section>
    446464
    447465<section anchor="caching.overview" title="Cache Operation">
     
    10551073<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Age"/>
    10561074  <x:ref>Age</x:ref> = <x:ref>delta-seconds</x:ref>
    10571075</artwork></figure>
    1058 <t anchor="rule.delta-seconds">
    1059   <x:anchor-alias value="delta-seconds" />
    1060   Age field-values are non-negative integers, representing time in seconds.
    1061 </t>
    1062 <figure><artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="delta-seconds" />
    1063   <x:ref>delta-seconds</x:ref>  = 1*<x:ref>DIGIT</x:ref>
    1064 </artwork></figure>
    10651076<t>
    1066    If a cache receives a value larger than the largest positive integer it can
    1067    represent, or if any of its age calculations overflows, it &MUST; transmit
    1068    an Age header field with a field-value of 2147483648 (2<x:sup>31</x:sup>).
    1069    Recipients parsing the Age header field-value &SHOULD; use an arithmetic type of
    1070    at least 31 bits of range.
     1077  Age field-values are non-negative integers, representing time in seconds
     1078  (see <xref target="delta-seconds"/>).
    10711079</t>
    10721080<t>
    10731081   The presence of an Age header field in a response implies that a response
     
    27162724      "Cache Invalidation only happens upon successful responses"
    27172725    </t>
    27182726    <t>
     2727      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/282"/>:
     2728      "Recommend minimum sizes for protocol elements"
     2729    </t>
     2730    <t>
    27192731      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/289"/>:
    27202732      "Proxies don't 'understand' methods"
    27212733    </t>