Changeset 2605 for draft-ietf-httpbis

Timestamp:

30/01/14 00:34:05 (7 years ago)

Author:

fielding@…

Message:

(editorial) remove redundant ought to receive unbounded lengths that is covered by 2.5; note the security consideration regarding ignored header fields; see #531

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (2 diffs)
• p1-messaging.xml (modified) (2 diffs)

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

@@ -1249 +1249 @@
                   crafted to bypass security filters along the request chain.
                </p>
-               <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
-                  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&nbsp;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>).
+               <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&nbsp;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>).
                </p>
                <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.
                </p>
-               <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.
-               </p>
-               <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 such
+               <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.
+               </p>
+               <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
                   that the dropped value(s) can be safely ignored without changing the message framing or response semantics.
                </p>

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -1150 +1150 @@
 </t>
 <t>
-   HTTP does not place a pre-defined limit on the length of a request-line.
+   HTTP does not place a pre-defined limit on the length of a request-line,
+   as described in <xref target="conformance"/>.
    A server that receives a method longer than any that it implements
    &SHOULD; respond with a <x:ref>501 (Not Implemented)</x:ref> status code.
-   A server ought to be prepared to receive URIs of unbounded length, as
-   described in <xref target="conformance"/>, and &MUST; respond with a
-   <x:ref>414 (URI Too Long)</x:ref> status code if the received
-   request-target is longer than the server wishes to parse (see &status-414;).
+   A server that receives a request-target longer than any URI it wishes to
+   parse &MUST; respond with a
+   <x:ref>414 (URI Too Long)</x:ref> status code (see &status-414;).
 </t>
 <t>
@@ -1431 +1431 @@
 </t>
 <t>
-   A server ought to be prepared to receive request header fields of unbounded
-   length and &MUST; respond with an appropriate
-   <x:ref>4xx (Client Error)</x:ref> status code if the received header
-   field(s) are larger than the server wishes to process.
-</t>
-<t>
-   A client ought to be prepared to receive response header fields of
-   unbounded length.
+   A server that receives a request header field, or set of fields, larger
+   than it wishes to process &MUST; respond with an appropriate
+   <x:ref>4xx (Client Error)</x:ref> status code. Ignoring such header fields
+   would increase the server's vulnerability to request smuggling attacks.
+</t>
+<t>
    A client &MAY; discard or truncate received header fields that are larger
    than the client wishes to process if the field semantics are such that the