Changeset 2605 for draft-ietf-httpbis
- Timestamp:
- 30/01/14 00:34:05 (7 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2604 r2605 1249 1249 crafted to bypass security filters along the request chain. 1250 1250 </p> 1251 <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that 1252 it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server ought to be prepared to receive URIs of unbounded length, as described in <a href="#conformance" title="Conformance and Error Handling">Section 2.5</a>, and <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target is longer than the server wishes to parse (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 1251 <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line, as described in <a href="#conformance" title="Conformance and Error Handling">Section 2.5</a>. A server that receives a method longer than any that it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server that receives a request-target longer than any URI it wishes to parse <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 1253 1252 </p> 1254 1253 <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets. … … 1394 1393 semantics. 1395 1394 </p> 1396 <p id="rfc.section.3.2.5.p.2">A server ought to be prepared to receive request header fields of unbounded length and <em class="bcp14">MUST</em> respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code if the received header field(s) are larger than the server wishes to process.1397 </p> 1398 <p id="rfc.section.3.2.5.p.3">A client ought to be prepared to receive response header fields of unbounded length. A client<em class="bcp14">MAY</em> discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such1395 <p id="rfc.section.3.2.5.p.2">A server that receives a request header field, or set of fields, larger than it wishes to process <em class="bcp14">MUST</em> respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code. Ignoring such header fields would increase the server's vulnerability to request smuggling attacks. 1396 </p> 1397 <p id="rfc.section.3.2.5.p.3">A client <em class="bcp14">MAY</em> discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such 1399 1398 that the dropped value(s) can be safely ignored without changing the message framing or response semantics. 1400 1399 </p> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2604 r2605 1150 1150 </t> 1151 1151 <t> 1152 HTTP does not place a pre-defined limit on the length of a request-line. 1152 HTTP does not place a pre-defined limit on the length of a request-line, 1153 as described in <xref target="conformance"/>. 1153 1154 A server that receives a method longer than any that it implements 1154 1155 &SHOULD; respond with a <x:ref>501 (Not Implemented)</x:ref> status code. 1155 A server ought to be prepared to receive URIs of unbounded length, as 1156 described in <xref target="conformance"/>, and &MUST; respond with a 1157 <x:ref>414 (URI Too Long)</x:ref> status code if the received 1158 request-target is longer than the server wishes to parse (see &status-414;). 1156 A server that receives a request-target longer than any URI it wishes to 1157 parse &MUST; respond with a 1158 <x:ref>414 (URI Too Long)</x:ref> status code (see &status-414;). 1159 1159 </t> 1160 1160 <t> … … 1431 1431 </t> 1432 1432 <t> 1433 A server ought to be prepared to receive request header fields of unbounded 1434 length and &MUST; respond with an appropriate 1435 <x:ref>4xx (Client Error)</x:ref> status code if the received header 1436 field(s) are larger than the server wishes to process. 1437 </t> 1438 <t> 1439 A client ought to be prepared to receive response header fields of 1440 unbounded length. 1433 A server that receives a request header field, or set of fields, larger 1434 than it wishes to process &MUST; respond with an appropriate 1435 <x:ref>4xx (Client Error)</x:ref> status code. Ignoring such header fields 1436 would increase the server's vulnerability to request smuggling attacks. 1437 </t> 1438 <t> 1441 1439 A client &MAY; discard or truncate received header fields that are larger 1442 1440 than the client wishes to process if the field semantics are such that the
Note: See TracChangeset
for help on using the changeset viewer.