Ignore:
Timestamp:
01/07/11 16:56:52 (11 years ago)
Author:
julian.reschke@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1321 r1323  
    677677               <li>11.4&nbsp;&nbsp;&nbsp;<a href="#dns.spoofing">DNS Spoofing</a></li>
    678678               <li>11.5&nbsp;&nbsp;&nbsp;<a href="#attack.proxies">Proxies and Caching</a></li>
    679                <li>11.6&nbsp;&nbsp;&nbsp;<a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li>
     679               <li>11.6&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></li>
     680               <li>11.7&nbsp;&nbsp;&nbsp;<a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li>
    680681            </ul>
    681682         </li>
    … …  
    12751276      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.43"></span>  <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a>    = "\" ( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    12761277</pre><p id="rfc.section.3.2.p.14">Senders <em class="bcp14">SHOULD NOT</em> escape octets that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and ")").
     1278      </p>
     1279      <p id="rfc.section.3.2.p.15">HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with a 4xx status code if the received header
     1280         field(s) would be longer than the server wishes to handle.
     1281      </p>
     1282      <p id="rfc.section.3.2.p.16">A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.</p>
     1283      <p id="rfc.section.3.2.p.17">Various ad-hoc limitations on header length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets.
    12771284      </p>
    12781285      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="message.body" href="#message.body">Message Body</a></h2>
    … …  
    27362743         attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification.
    27372744      </p>
    2738       <h2 id="rfc.section.11.6"><a href="#rfc.section.11.6">11.6</a>&nbsp;<a id="attack.DoS" href="#attack.DoS">Denial of Service Attacks on Proxies</a></h2>
    2739       <p id="rfc.section.11.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>
     2745      <h2 id="rfc.section.11.6"><a href="#rfc.section.11.6">11.6</a>&nbsp;<a id="attack.protocol.element.size.overflows" href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></h2>
     2746      <p id="rfc.section.11.6.p.1">Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform
     2747         a Denial of Service against implementations that accept fields with unlimited lengths.
     2748      </p>
     2749      <p id="rfc.section.11.6.p.2">To promote interoperability, this specification makes specific recommendations for size limits on request-targets (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>) and blocks of header fields (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected
     2750         that most implementations will choose substantially higher limits.
     2751      </p>
     2752      <p id="rfc.section.11.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 8.4</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2753      </p>
     2754      <p id="rfc.section.11.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
     2755      </p>
     2756      <h2 id="rfc.section.11.7"><a href="#rfc.section.11.7">11.7</a>&nbsp;<a id="attack.DoS" href="#attack.DoS">Denial of Service Attacks on Proxies</a></h2>
     2757      <p id="rfc.section.11.7.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>
    27402758      <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
    27412759      <p id="rfc.section.12.p.1">HTTP has evolved considerably over the years. It has benefited from a large and active developer community — the many people
    … …  
    35943612      <ul>
    35953613         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/273">http://tools.ietf.org/wg/httpbis/trac/ticket/273</a>&gt;: "HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT"
     3614         </li>
     3615         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/282">http://tools.ietf.org/wg/httpbis/trac/ticket/282</a>&gt;: "Recommend minimum sizes for protocol elements"
    35963616         </li>
    35973617         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/283">http://tools.ietf.org/wg/httpbis/trac/ticket/283</a>&gt;: "Set expectations around buffering"
    … …  
    38203840            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    38213841                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">7.1.1</a>, <a href="#Pad1995"><b>13.2</b></a></li>
    3822                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">4.1.2</a>, <a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.4">5.1.1</a>, <a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a>, <a href="#rfc.xref.Part2.7">7.2.3</a>, <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">9.8</a>, <a href="#Part2"><b>13.1</b></a><ul>
     3842                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">4.1.2</a>, <a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.4">5.1.1</a>, <a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a>, <a href="#rfc.xref.Part2.7">7.2.3</a>, <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">9.8</a>, <a href="#rfc.xref.Part2.12">11.6</a>, <a href="#rfc.xref.Part2.13">11.6</a>, <a href="#Part2"><b>13.1</b></a><ul>
    38233843                        <li><em>Section 7.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a></li>
    38243844                        <li><em>Section 7.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">4.1.2</a></li>
    … …  
    38283848                        <li><em>Section 8.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a></li>
    38293849                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">9.8</a></li>
    3830                         <li><em>Section 8.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4.1.2</a></li>
     3850                        <li><em>Section 8.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">11.6</a></li>
     3851                        <li><em>Section 8.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.12">11.6</a></li>
    38313852                        <li><em>Section 9.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a></li>
    38323853                     </ul>

  • 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"

  • draft-ietf-httpbis/latest/p6-cache.html

    r1321 r1323  
    550550                  </ul>
    551551               </li>
     552               <li>1.5&nbsp;&nbsp;&nbsp;<a href="#delta-seconds">Delta Seconds</a></li>
    552553            </ul>
    553554         </li>
    … …  
    740741  <a href="#abnf.dependencies" class="smpl">pseudonym</a>     = &lt;pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a>&gt;
    741742  <a href="#abnf.dependencies" class="smpl">uri-host</a>      = &lt;uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    742 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="caching.overview" href="#caching.overview">Cache Operation</a></h1>
     743</pre><h2 id="rfc.section.1.5"><a href="#rfc.section.1.5">1.5</a>&nbsp;<a id="delta-seconds" href="#delta-seconds">Delta Seconds</a></h2>
     744      <p id="rfc.section.1.5.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p>
     745      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
     746</pre><p id="rfc.section.1.5.p.3">If an implementation receives a delta-seconds value larger than the largest positive integer it can represent, or if any of
     747         its subsequent calculations overflows, it <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> send delta-seconds with a value greater than 2147483648.
     748      </p>
     749      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="caching.overview" href="#caching.overview">Cache Operation</a></h1>
    743750      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h2>
    744751      <p id="rfc.section.2.1.p.1">A cache <em class="bcp14">MUST NOT</em> store a response to any request, unless:
    … …  
    834841         algorithms, but does impose worst-case constraints on their results.
    835842      </p>
    836       <div id="rfc.figure.u.3"></div>
     843      <div id="rfc.figure.u.4"></div>
    837844      <p>The calculation to determine if a response is fresh is:</p>  <pre class="text">   response_is_fresh = (freshness_lifetime &gt; current_age)
    838845</pre> <p id="rfc.section.2.3.p.6">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
    … …  
    918925         </li>
    919926      </ol>
    920       <div id="rfc.figure.u.4"></div> <pre class="text">  apparent_age = max(0, response_time - date_value);
     927      <div id="rfc.figure.u.5"></div> <pre class="text">  apparent_age = max(0, response_time - date_value);
    921928
    922929  response_delay = response_time - request_time;
    923930  corrected_age_value = age_value + response_delay; 
    924 </pre> <div id="rfc.figure.u.5"></div>
     931</pre> <div id="rfc.figure.u.6"></div>
    925932      <p>These are combined as</p>  <pre class="text">  corrected_initial_age = max(apparent_age, corrected_age_value);
    926933</pre><p id="rfc.section.2.3.2.p.11">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response
    927934         was last validated by the origin server to the corrected_initial_age.
    928935      </p>
    929       <div id="rfc.figure.u.6"></div><pre class="text">  resident_time = now - response_time;
     936      <div id="rfc.figure.u.7"></div><pre class="text">  resident_time = now - response_time;
    930937  current_age = corrected_initial_age + resident_time;
    931938</pre><h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3>
    … …  
    10481055         validated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
    10491056      </p>
    1050       <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#header.age" class="smpl">Age</a> = <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
    1051 </pre><div id="rule.delta-seconds">
    1052          <p id="rfc.section.3.1.p.3">  Age field-values are non-negative integers, representing time in seconds.</p>
    1053       </div>
    1054       <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
    1055 </pre><p id="rfc.section.3.1.p.5">If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows,
    1056          it <em class="bcp14">MUST</em> transmit an Age header field with a field-value of 2147483648 (2<sup>31</sup>). Recipients parsing the Age header field-value <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range.
    1057       </p>
    1058       <p id="rfc.section.3.1.p.6">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not
     1057      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#header.age" class="smpl">Age</a> = <a href="#delta-seconds" class="smpl">delta-seconds</a>
     1058</pre><p id="rfc.section.3.1.p.3">Age field-values are non-negative integers, representing time in seconds (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.5</a>).
     1059      </p>
     1060      <p id="rfc.section.3.1.p.4">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not
    10591061         true, since HTTP/1.0 caches might not implement the Age header field.
    10601062      </p>
    … …  
    10861088       "no-cache"
    10871089     / "no-store"
    1088      / "max-age" "=" <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
    1089      / "max-stale" [ "=" <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> ]
    1090      / "min-fresh" "=" <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
     1090     / "max-age" "=" <a href="#delta-seconds" class="smpl">delta-seconds</a>
     1091     / "max-stale" [ "=" <a href="#delta-seconds" class="smpl">delta-seconds</a> ]
     1092     / "min-fresh" "=" <a href="#delta-seconds" class="smpl">delta-seconds</a>
    10911093     / "no-transform"
    10921094     / "only-if-cached"
    … …  
    11581160     / "must-revalidate"
    11591161     / "proxy-revalidate"
    1160      / "max-age" "=" <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
    1161      / "s-maxage" "=" <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
     1162     / "max-age" "=" <a href="#delta-seconds" class="smpl">delta-seconds</a>
     1163     / "s-maxage" "=" <a href="#delta-seconds" class="smpl">delta-seconds</a>
    11621164     / <a href="#header.cache-control" class="smpl">cache-extension</a>
    11631165</pre><p id="rfc.section.3.2.2.p.2"> <dfn>public</dfn>  <span id="rfc.iref.c.12"></span>  <span id="rfc.iref.p.2"></span> 
    … …  
    17551757 ) / ( "s-maxage=" delta-seconds ) / cache-extension
    17561758
    1757 <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*DIGIT
     1759<a href="#delta-seconds" class="smpl">delta-seconds</a> = 1*DIGIT
    17581760
    17591761<a href="#header.pragma" class="smpl">extension-pragma</a> = token [ "=" ( token / quoted-string ) ]
    … …  
    19671969         </li>
    19681970         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/235">http://tools.ietf.org/wg/httpbis/trac/ticket/235</a>&gt;: "Cache Invalidation only happens upon successful responses"
     1971         </li>
     1972         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/282">http://tools.ietf.org/wg/httpbis/trac/ticket/282</a>&gt;: "Recommend minimum sizes for protocol elements"
    19691973         </li>
    19701974         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/289">http://tools.ietf.org/wg/httpbis/trac/ticket/289</a>&gt;: "Proxies don't 'understand' methods"
    … …  
    20192023                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    20202024                     <ul>
    2021                         <li><tt>Age</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>3.1</b></a></li>
     2025                        <li><tt>Age</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>3.1</b></a></li>
    20222026                        <li><tt>Cache-Control</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>3.2</b></a></li>
    20232027                        <li><tt>cache-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>3.2</b></a></li>
    20242028                        <li><tt>cache-request-directive</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>3.2.1</b></a></li>
    20252029                        <li><tt>cache-response-directive</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>3.2.2</b></a></li>
    2026                         <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>3.1</b></a></li>
     2030                        <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.5</b></a></li>
    20272031                        <li><tt>Expires</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>3.3</b></a></li>
    20282032                        <li><tt>extension-pragma</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>3.4</b></a></li>

  • draft-ietf-httpbis/latest/p6-cache.xml

    r1321 r1323  
    441441</artwork></figure>
    442442</section>
    443 
    444 </section>
     443</section>
     444
     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>
     461</section>
     462
    445463</section>
    446464
    … …  
    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>
    1065 <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.
     1076<t>
     1077  Age field-values are non-negative integers, representing time in seconds
     1078  (see <xref target="delta-seconds"/>).
    10711079</t>
    10721080<t>
    … …  
    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"
Note: See TracChangeset for help on using the changeset viewer.