Ticket #282: 282.diff

p1-messaging.xml

@@ -35 +35 @@
   <!ENTITY status-1xx             "<xref target='Part2' x:rel='#status.1xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY status-203             "<xref target='Part2' x:rel='#status.203' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY status-3xx             "<xref target='Part2' x:rel='#status.3xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY status-413             "<xref target='Part2' x:rel='#status.413' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY status-414             "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
 ]>
 <?rfc toc="yes" ?>
@@ -1364 +1365 @@
    (i.e., other than the backslash octet "\" and the parentheses "(" and
    ")").
 </t>
+<t>
+   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 header fields of unbounded length and respond with the 413 (Request
+   Entity Too Large) status code if the received header field(s) would be longer
+   than the server wishes to handle (see &status-413;).
+</t>
+<t>
+   A client that receives response headers that are longer than it wishes to
+   handle can only treat it as a server error.
+</t>
+<t>
+   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 fields have 4000 or more octets.
+</t>
 </section>
 
 <section title="Message Body" anchor="message.body">
@@ -4048 +4065 @@
 </t>
 </section>
 
+<section title="Protocol Element Size Overflows" anchor="attack.protocol.element.size.overflows">
+<t>
+   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.
+</t>
+<t>
+   To promote interoperability, this specification makes specific
+   recommendations for size limits on request-targets (<xref target="request-target"/>)
+   and blocks of header fields (<xref target="header.fields"/>). 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.
+</t>
+<t>
+   This specification also provides a way for servers to reject messages that
+   have request-targets that are too long (&status-414;) or request entities
+   that are too large (&status-413;).
+</t>
+<t>
+   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.
+</t>
+</section>
+
 <section title="Denial of Service Attacks on Proxies" anchor="attack.DoS">
 <t>
    They exist. They are hard to defend against. Research continues.
@@ -5921 +5964 @@
       "HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT"
     </t>
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/282"/>:
+      "Recommend minimum sizes for protocol elements"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/283"/>:
       "Set expectations around buffering"
     </t>

p6-cache.xml

@@ -440 +440 @@
   <x:ref>uri-host</x:ref>      = &lt;uri-host, defined in &uri;&gt;
 </artwork></figure>
 </section>
+</section>
 
+<section title="Delta Seconds" anchor="delta-seconds">
+<t>
+   The delta-seconds rule specifies a non-negative integer, representing time
+   in seconds.
+</t>
+<figure><artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="delta-seconds" />
+  <x:ref>delta-seconds</x:ref>  = 1*<x:ref>DIGIT</x:ref>
+</artwork></figure>
+<t>
+   If an implementation receives a delta-seconds value larger than the largest
+   positive integer it can represent, or if any of its subsequent calculations
+   overflows, it &MUST; consider the value to be 2147483648 (2<x:sup>31</x:sup>).
+   Recipients parsing a delta-seconds value &SHOULD; use an arithmetic type of
+   at least 31 bits of range, and senders &MUST-NOT; send delta-seconds with a
+   value greater than 2147483648.
+</t>
 </section>
+
 </section>
 
 <section anchor="caching.overview" title="Cache Operation">
@@ -1055 +1073 @@
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Age"/>
   <x:ref>Age</x:ref> = <x:ref>delta-seconds</x:ref>
 </artwork></figure>
-<t anchor="rule.delta-seconds">
-  <x:anchor-alias value="delta-seconds" />
-  Age field-values are non-negative integers, representing time in seconds.
-</t>
-<figure><artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="delta-seconds" />
-  <x:ref>delta-seconds</x:ref>  = 1*<x:ref>DIGIT</x:ref>
-</artwork></figure>
 <t>
-   If a cache receives a value larger than the largest positive integer it can
-   represent, or if any of its age calculations overflows, it &MUST; transmit
-   an Age header field with a field-value of 2147483648 (2<x:sup>31</x:sup>). 
-   Recipients parsing the Age header field-value &SHOULD; use an arithmetic type of 
-   at least 31 bits of range.
+  Age field-values are non-negative integers, representing time in seconds
+  (see <xref target="delta-seconds"/>).
 </t>
 <t>
    The presence of an Age header field in a response implies that a response
@@ -2716 +2724 @@
       "Cache Invalidation only happens upon successful responses"
     </t>
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/282"/>:
+      "Recommend minimum sizes for protocol elements"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/289"/>:
       "Proxies don't 'understand' methods"
     </t>