Changeset 1323 for draft-ietf-httpbis/latest
- Timestamp:
- 01/07/11 16:56:52 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1321 r1323 677 677 <li>11.4 <a href="#dns.spoofing">DNS Spoofing</a></li> 678 678 <li>11.5 <a href="#attack.proxies">Proxies and Caching</a></li> 679 <li>11.6 <a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li> 679 <li>11.6 <a href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></li> 680 <li>11.7 <a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li> 680 681 </ul> 681 682 </li> … … 1275 1276 <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> ) 1276 1277 </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. 1277 1284 </p> 1278 1285 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="message.body" href="#message.body">Message Body</a></h2> … … 2736 2743 attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification. 2737 2744 </p> 2738 <h2 id="rfc.section.11.6"><a href="#rfc.section.11.6">11.6</a> <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> <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 4.1.2</a>) and blocks of header fields (<a href="#header.fields" title="Header Fields">Section 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> <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> 2740 2758 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 2741 2759 <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 … … 3594 3612 <ul> 3595 3613 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/273">http://tools.ietf.org/wg/httpbis/trac/ticket/273</a>>: "HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT" 3614 </li> 3615 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/282">http://tools.ietf.org/wg/httpbis/trac/ticket/282</a>>: "Recommend minimum sizes for protocol elements" 3596 3616 </li> 3597 3617 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/283">http://tools.ietf.org/wg/httpbis/trac/ticket/283</a>>: "Set expectations around buffering" … … 3820 3840 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3821 3841 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">7.1.1</a>, <a href="#Pad1995"><b>13.2</b></a></li> 3822 <li><em>Part2</em> <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> <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> 3823 3843 <li><em>Section 7.1.2</em> <a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a></li> 3824 3844 <li><em>Section 7.9</em> <a href="#rfc.xref.Part2.2">4.1.2</a></li> … … 3828 3848 <li><em>Section 8.2.4</em> <a href="#rfc.xref.Part2.1">2.4</a></li> 3829 3849 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.11">9.8</a></li> 3830 <li><em>Section 8.4.15</em> <a href="#rfc.xref.Part2.3">4.1.2</a></li> 3850 <li><em>Section 8.4</em> <a href="#rfc.xref.Part2.13">11.6</a></li> 3851 <li><em>Section 8.4.15</em> <a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.12">11.6</a></li> 3831 3852 <li><em>Section 9.2</em> <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a></li> 3832 3853 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1321 r1323 36 36 <!ENTITY status-203 "<xref target='Part2' x:rel='#status.203' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 37 37 <!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'/>"> 38 39 <!ENTITY status-414 "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 39 40 ]> … … 1364 1365 (i.e., other than the backslash octet "\" and the parentheses "(" and 1365 1366 ")"). 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. 1366 1383 </t> 1367 1384 </section> … … 4049 4066 </section> 4050 4067 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 4051 4094 <section title="Denial of Service Attacks on Proxies" anchor="attack.DoS"> 4052 4095 <t> … … 5922 5965 </t> 5923 5966 <t> 5967 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/282"/>: 5968 "Recommend minimum sizes for protocol elements" 5969 </t> 5970 <t> 5924 5971 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/283"/>: 5925 5972 "Set expectations around buffering" -
draft-ietf-httpbis/latest/p6-cache.html
r1321 r1323 550 550 </ul> 551 551 </li> 552 <li>1.5 <a href="#delta-seconds">Delta Seconds</a></li> 552 553 </ul> 553 554 </li> … … 740 741 <a href="#abnf.dependencies" class="smpl">pseudonym</a> = <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>> 741 742 <a href="#abnf.dependencies" class="smpl">uri-host</a> = <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>> 742 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <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> <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> <a id="caching.overview" href="#caching.overview">Cache Operation</a></h1> 743 750 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h2> 744 751 <p id="rfc.section.2.1.p.1">A cache <em class="bcp14">MUST NOT</em> store a response to any request, unless: … … 834 841 algorithms, but does impose worst-case constraints on their results. 835 842 </p> 836 <div id="rfc.figure.u. 3"></div>843 <div id="rfc.figure.u.4"></div> 837 844 <p>The calculation to determine if a response is fresh is:</p> <pre class="text"> response_is_fresh = (freshness_lifetime > current_age) 838 845 </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 2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>. … … 918 925 </li> 919 926 </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); 921 928 922 929 response_delay = response_time - request_time; 923 930 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> 925 932 <p>These are combined as</p> <pre class="text"> corrected_initial_age = max(apparent_age, corrected_age_value); 926 933 </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 927 934 was last validated by the origin server to the corrected_initial_age. 928 935 </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; 930 937 current_age = corrected_initial_age + resident_time; 931 938 </pre><h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3> … … 1048 1055 validated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>. 1049 1056 </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 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 1059 1061 true, since HTTP/1.0 caches might not implement the Age header field. 1060 1062 </p> … … 1086 1088 "no-cache" 1087 1089 / "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> 1091 1093 / "no-transform" 1092 1094 / "only-if-cached" … … 1158 1160 / "must-revalidate" 1159 1161 / "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> 1162 1164 / <a href="#header.cache-control" class="smpl">cache-extension</a> 1163 1165 </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> … … 1755 1757 ) / ( "s-maxage=" delta-seconds ) / cache-extension 1756 1758 1757 <a href="# rule.delta-seconds" class="smpl">delta-seconds</a> = 1*DIGIT1759 <a href="#delta-seconds" class="smpl">delta-seconds</a> = 1*DIGIT 1758 1760 1759 1761 <a href="#header.pragma" class="smpl">extension-pragma</a> = token [ "=" ( token / quoted-string ) ] … … 1967 1969 </li> 1968 1970 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/235">http://tools.ietf.org/wg/httpbis/trac/ticket/235</a>>: "Cache Invalidation only happens upon successful responses" 1971 </li> 1972 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/282">http://tools.ietf.org/wg/httpbis/trac/ticket/282</a>>: "Recommend minimum sizes for protocol elements" 1969 1973 </li> 1970 1974 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/289">http://tools.ietf.org/wg/httpbis/trac/ticket/289</a>>: "Proxies don't 'understand' methods" … … 2019 2023 <li><tt>Grammar</tt> 2020 2024 <ul> 2021 <li><tt>Age</tt> <a href="#rfc.iref.g. 1"><b>3.1</b></a></li>2025 <li><tt>Age</tt> <a href="#rfc.iref.g.2"><b>3.1</b></a></li> 2022 2026 <li><tt>Cache-Control</tt> <a href="#rfc.iref.g.3"><b>3.2</b></a></li> 2023 2027 <li><tt>cache-extension</tt> <a href="#rfc.iref.g.4"><b>3.2</b></a></li> 2024 2028 <li><tt>cache-request-directive</tt> <a href="#rfc.iref.g.5"><b>3.2.1</b></a></li> 2025 2029 <li><tt>cache-response-directive</tt> <a href="#rfc.iref.g.6"><b>3.2.2</b></a></li> 2026 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g. 2"><b>3.1</b></a></li>2030 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.1"><b>1.5</b></a></li> 2027 2031 <li><tt>Expires</tt> <a href="#rfc.iref.g.7"><b>3.3</b></a></li> 2028 2032 <li><tt>extension-pragma</tt> <a href="#rfc.iref.g.10"><b>3.4</b></a></li> -
draft-ietf-httpbis/latest/p6-cache.xml
r1321 r1323 441 441 </artwork></figure> 442 442 </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 445 463 </section> 446 464 … … 1056 1074 <x:ref>Age</x:ref> = <x:ref>delta-seconds</x:ref> 1057 1075 </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"/>). 1071 1079 </t> 1072 1080 <t> … … 2717 2725 </t> 2718 2726 <t> 2727 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/282"/>: 2728 "Recommend minimum sizes for protocol elements" 2729 </t> 2730 <t> 2719 2731 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/289"/>: 2720 2732 "Proxies don't 'understand' methods"
Note: See TracChangeset
for help on using the changeset viewer.