Changeset 2535

Timestamp:

04/01/14 02:33:26 (6 years ago)

Author:

fielding@…

Message:

move that paragraph to the right section; see #540

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

@@ -1285 +1285 @@
                the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
             </p>
-            <p id="rfc.section.3.2.p.4">Since messages are parsed using a generic algorithm, independent of the individual header field names, the contents within
-               a given field value are not parsed until a later stage of message interpretation (usually after the message's entire header
-               section has been processed). Consequently, this specification does not use ABNF rules to define the "Field-Name: Field Value"
-               pair, as was done in previous editions. Instead, this specification uses ABNF rules which are named according to each registered
-               field name, wherein the rule defines the valid grammar for that field's corresponding field values (i.e., after the field-value
-               has been extracted from the header section by a generic field parser).
-            </p>
             <div id="field.extensibility">
                <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a href="#field.extensibility">Field Extensibility</a></h3>
@@ -1360 +1353 @@
             <div id="field.parsing">
                <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;<a href="#field.parsing">Field Parsing</a></h3>
-               <p id="rfc.section.3.2.4.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace
+               <p id="rfc.section.3.2.4.p.1">Messages are parsed using a generic algorithm, independent of the individual header field names. The contents within a given
+                  field value are not parsed until a later stage of message interpretation (usually after the message's entire header section
+                  has been processed). Consequently, this specification does not use ABNF rules to define each "Field-Name: Field Value" pair,
+                  as was done in previous editions. Instead, this specification uses ABNF rules which are named according to each registered
+                  field name, wherein the rule defines the valid grammar for that field's corresponding field values (i.e., after the field-value
+                  has been extracted from the header section by a generic field parser).
+               </p>
+               <p id="rfc.section.3.2.4.p.2">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace
                   have led to security vulnerabilities in request routing and response handling. A server <em class="bcp14">MUST</em> reject any received request message that contains whitespace between a header field-name and colon with a response code of <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>. A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream.
                </p>
-               <p id="rfc.section.3.2.4.p.2">A field value is preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading
+               <p id="rfc.section.3.2.4.p.3">A field value is preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading
                   or trailing white space: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace
                   octet of the field value ought to be excluded by parsers when extracting the field value from a header field.
                </p>
-               <p id="rfc.section.3.2.4.p.3">A recipient of field-content containing multiple sequential octets of optional (OWS) or required (RWS) whitespace <em class="bcp14">SHOULD</em> either replace the sequence with a single SP or transform any non-SP octets in the sequence to SP octets before interpreting
+               <p id="rfc.section.3.2.4.p.4">A recipient of field-content containing multiple sequential octets of optional (OWS) or required (RWS) whitespace <em class="bcp14">SHOULD</em> either replace the sequence with a single SP or transform any non-SP octets in the sequence to SP octets before interpreting
                   the field value or forwarding the message downstream.
                </p>
-               <p id="rfc.section.3.2.4.p.4">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
+               <p id="rfc.section.3.2.4.p.5">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
                   space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type
                   (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;8.3.1</a>). A sender <em class="bcp14">MUST NOT</em> generate a message that includes line folding (i.e., that has any field-value that contains a match to the <a href="#header.fields" class="smpl">obs-fold</a> rule) unless the message is intended for packaging within the message/http media type.
                </p>
-               <p id="rfc.section.3.2.4.p.5">A server that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a request message that is not within a message/http container <em class="bcp14">MUST</em> either reject the message by sending a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>, preferably with a representation explaining that obsolete line folding is unacceptable, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream.
-               </p>
-               <p id="rfc.section.3.2.4.p.6">A proxy or gateway that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> either discard the message and replace it with a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response, preferably with a representation explaining that unacceptable line folding was received, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream.
-               </p>
-               <p id="rfc.section.3.2.4.p.7">A user agent that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value.
-               </p>
-               <p id="rfc.section.3.2.4.p.8">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> charset, supporting other charsets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. A recipient <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data.
+               <p id="rfc.section.3.2.4.p.6">A server that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a request message that is not within a message/http container <em class="bcp14">MUST</em> either reject the message by sending a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>, preferably with a representation explaining that obsolete line folding is unacceptable, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream.
+               </p>
+               <p id="rfc.section.3.2.4.p.7">A proxy or gateway that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> either discard the message and replace it with a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response, preferably with a representation explaining that unacceptable line folding was received, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream.
+               </p>
+               <p id="rfc.section.3.2.4.p.8">A user agent that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value.
+               </p>
+               <p id="rfc.section.3.2.4.p.9">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> charset, supporting other charsets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. A recipient <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data.
                </p>
             </div>

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

@@ -1235 +1235 @@
    timestamp for the message in which it appears.
 </t>
-<t>
-   Since messages are parsed using a generic algorithm, independent of the
-   individual header field names, the contents within a given field value are
-   not parsed until a later stage of message interpretation (usually after the
-   message's entire header section has been processed).
-   Consequently, this specification does not use ABNF rules to define the
-   "Field-Name: Field Value" pair, as was done in previous editions.
-   Instead, this specification uses ABNF rules which are named according to
-   each registered field name, wherein the rule defines the valid grammar for
-   that field's corresponding field values (i.e., after the field-value
-   has been extracted from the header section by a generic field parser).
-</t>
 
 <section title="Field Extensibility" anchor="field.extensibility">
@@ -1357 +1345 @@
 
 <section title="Field Parsing" anchor="field.parsing">
+<t>
+   Messages are parsed using a generic algorithm, independent of the
+   individual header field names. The contents within a given field value are
+   not parsed until a later stage of message interpretation (usually after the
+   message's entire header section has been processed).
+   Consequently, this specification does not use ABNF rules to define each
+   "Field-Name: Field Value" pair, as was done in previous editions.
+   Instead, this specification uses ABNF rules which are named according to
+   each registered field name, wherein the rule defines the valid grammar for
+   that field's corresponding field values (i.e., after the field-value
+   has been extracted from the header section by a generic field parser).
+</t>
 <t>
    No whitespace is allowed between the header field-name and colon.