Ignore:
Timestamp:
04/01/14 02:33:26 (7 years ago)
Author:
fielding@…
Message:

move that paragraph to the right section; see #540

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2534 r2535  
    12851285               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.
    12861286            </p>
    1287             <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
    1288                a given field value are not parsed until a later stage of message interpretation (usually after the message's entire header
    1289                section has been processed). Consequently, this specification does not use ABNF rules to define the "Field-Name: Field Value"
    1290                pair, as was done in previous editions. Instead, this specification uses ABNF rules which are named according to each registered
    1291                field name, wherein the rule defines the valid grammar for that field's corresponding field values (i.e., after the field-value
    1292                has been extracted from the header section by a generic field parser).
    1293             </p>
    12941287            <div id="field.extensibility">
    12951288               <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>
     
    13601353            <div id="field.parsing">
    13611354               <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>
    1362                <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
     1355               <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
     1356                  field value are not parsed until a later stage of message interpretation (usually after the message's entire header section
     1357                  has been processed). Consequently, this specification does not use ABNF rules to define each "Field-Name: Field Value" pair,
     1358                  as was done in previous editions. Instead, this specification uses ABNF rules which are named according to each registered
     1359                  field name, wherein the rule defines the valid grammar for that field's corresponding field values (i.e., after the field-value
     1360                  has been extracted from the header section by a generic field parser).
     1361               </p>
     1362               <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
    13631363                  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.
    13641364               </p>
    1365                <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
     1365               <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
    13661366                  or trailing white space: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace
    13671367                  octet of the field value ought to be excluded by parsers when extracting the field value from a header field.
    13681368               </p>
    1369                <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
     1369               <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
    13701370                  the field value or forwarding the message downstream.
    13711371               </p>
    1372                <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
     1372               <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
    13731373                  space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type
    13741374                  (<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.
    13751375               </p>
    1376                <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.
    1377                </p>
    1378                <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.
    1379                </p>
    1380                <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.
    1381                </p>
    1382                <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.
     1376               <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.
     1377               </p>
     1378               <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.
     1379               </p>
     1380               <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.
     1381               </p>
     1382               <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.
    13831383               </p>
    13841384            </div>
Note: See TracChangeset for help on using the changeset viewer.