Changeset 2535
- Timestamp:
- 04/01/14 02:33:26 (8 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2534 r2535 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. 1286 1286 </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 within1288 a given field value are not parsed until a later stage of message interpretation (usually after the message's entire header1289 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 registered1291 field name, wherein the rule defines the valid grammar for that field's corresponding field values (i.e., after the field-value1292 has been extracted from the header section by a generic field parser).1293 </p>1294 1287 <div id="field.extensibility"> 1295 1288 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a href="#field.extensibility">Field Extensibility</a></h3> … … 1360 1353 <div id="field.parsing"> 1361 1354 <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a> <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 1363 1363 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. 1364 1364 </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 leading1365 <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 1366 1366 or trailing white space: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace 1367 1367 octet of the field value ought to be excluded by parsers when extracting the field value from a header field. 1368 1368 </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 interpreting1369 <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 1370 1370 the field value or forwarding the message downstream. 1371 1371 </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 one1372 <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 1373 1373 space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type 1374 1374 (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 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. 1375 1375 </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. 1383 1383 </p> 1384 1384 </div> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2534 r2535 1235 1235 timestamp for the message in which it appears. 1236 1236 </t> 1237 <t>1238 Since messages are parsed using a generic algorithm, independent of the1239 individual header field names, the contents within a given field value are1240 not parsed until a later stage of message interpretation (usually after the1241 message's entire header section has been processed).1242 Consequently, this specification does not use ABNF rules to define the1243 "Field-Name: Field Value" pair, as was done in previous editions.1244 Instead, this specification uses ABNF rules which are named according to1245 each registered field name, wherein the rule defines the valid grammar for1246 that field's corresponding field values (i.e., after the field-value1247 has been extracted from the header section by a generic field parser).1248 </t>1249 1237 1250 1238 <section title="Field Extensibility" anchor="field.extensibility"> … … 1357 1345 1358 1346 <section title="Field Parsing" anchor="field.parsing"> 1347 <t> 1348 Messages are parsed using a generic algorithm, independent of the 1349 individual header field names. The contents within a given field value are 1350 not parsed until a later stage of message interpretation (usually after the 1351 message's entire header section has been processed). 1352 Consequently, this specification does not use ABNF rules to define each 1353 "Field-Name: Field Value" pair, as was done in previous editions. 1354 Instead, this specification uses ABNF rules which are named according to 1355 each registered field name, wherein the rule defines the valid grammar for 1356 that field's corresponding field values (i.e., after the field-value 1357 has been extracted from the header section by a generic field parser). 1358 </t> 1359 1359 <t> 1360 1360 No whitespace is allowed between the header field-name and colon.
Note: See TracChangeset
for help on using the changeset viewer.