Ticket #282: 282.diff
File 282.diff, 6.2 KB (added by julian.reschke@…, 11 years ago) |
---|
-
p1-messaging.xml
35 35 <!ENTITY status-1xx "<xref target='Part2' x:rel='#status.1xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 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-413 "<xref target='Part2' x:rel='#status.413' 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 ]> 40 41 <?rfc toc="yes" ?> … … 1364 1365 (i.e., other than the backslash octet "\" and the parentheses "(" and 1365 1366 ")"). 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 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> 1367 1384 </section> 1368 1385 1369 1386 <section title="Message Body" anchor="message.body"> … … 4048 4065 </t> 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-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 4051 4094 <section title="Denial of Service Attacks on Proxies" anchor="attack.DoS"> 4052 4095 <t> 4053 4096 They exist. They are hard to defend against. Research continues. … … 5921 5964 "HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT" 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" 5926 5973 </t> -
p6-cache.xml
440 440 <x:ref>uri-host</x:ref> = <uri-host, defined in &uri;> 441 441 </artwork></figure> 442 442 </section> 443 </section> 443 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> 444 461 </section> 462 445 463 </section> 446 464 447 465 <section anchor="caching.overview" title="Cache Operation"> … … 1055 1073 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Age"/> 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 1076 <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"/>). 1071 1079 </t> 1072 1080 <t> 1073 1081 The presence of an Age header field in a response implies that a response … … 2716 2724 "Cache Invalidation only happens upon successful responses" 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" 2721 2733 </t>