Changeset 395 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 15/11/08 07:49:55 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r391 r395 304 304 <section title="Syntax Notation" anchor="notation"> 305 305 <iref primary="true" item="Grammar" subitem="ALPHA"/> 306 <iref primary="true" item="Grammar" subitem="CHAR"/>307 306 <iref primary="true" item="Grammar" subitem="CR"/> 308 307 <iref primary="true" item="Grammar" subitem="CRLF"/> … … 311 310 <iref primary="true" item="Grammar" subitem="DQUOTE"/> 312 311 <iref primary="true" item="Grammar" subitem="HEXDIG"/> 313 <iref primary="true" item="Grammar" subitem="HTAB"/>314 312 <iref primary="true" item="Grammar" subitem="LF"/> 315 313 <iref primary="true" item="Grammar" subitem="OCTET"/> 316 314 <iref primary="true" item="Grammar" subitem="SP"/> 315 <iref primary="true" item="Grammar" subitem="VCHAR"/> 317 316 <iref primary="true" item="Grammar" subitem="WSP"/> 318 317 <t anchor="core.rules"> 319 318 <x:anchor-alias value="ALPHA"/> 320 <x:anchor-alias value="CHAR"/>321 319 <x:anchor-alias value="CTL"/> 322 320 <x:anchor-alias value="CR"/> … … 325 323 <x:anchor-alias value="DQUOTE"/> 326 324 <x:anchor-alias value="HEXDIG"/> 327 <x:anchor-alias value="HTAB"/>328 325 <x:anchor-alias value="LF"/> 329 326 <x:anchor-alias value="OCTET"/> 330 327 <x:anchor-alias value="SP"/> 328 <x:anchor-alias value="VCHAR"/> 331 329 <x:anchor-alias value="WSP"/> 332 330 This specification uses the Augmented Backus-Naur Form (ABNF) notation 333 331 of <xref target="RFC5234"/>. The following core rules are included by 334 332 reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>: 335 ALPHA (letters), CHAR (any <xref target="USASCII"/> character, 336 excluding NUL), CR (carriage return), CRLF (CR LF), CTL (controls), 333 ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), 337 334 DIGIT (decimal 0-9), DQUOTE (double quote), 338 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), 339 LF (line feed), OCTET (any 8-bit sequence of data), SP (space) 335 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), 336 OCTET (any 8-bit sequence of data), SP (space), 337 VCHAR (any visible <xref target="USASCII"/> character), 340 338 and WSP (white space). 341 339 </t> … … 388 386 </t> 389 387 <t anchor="rule.LWS"> 390 All linear white space (LWS) in header field-values has the same semantics as SP. A 391 recipient &MAY; replace any such linear white space with a single SP before 388 This specification uses three rules to denote the use of linear 389 whitespace: OWS (optional whitespace), RWS (required whitespace), and 390 BWS ("bad" whitespace). 391 </t> 392 <t> 393 The OWS rule is used where zero or more linear white space characters may 394 appear. OWS &SHOULD; either not be produced or be produced as a single SP 395 character. Multiple OWS characters that occur within field-content &SHOULD; 396 be replaced with a single SP before interpreting the field value or 397 forwarding the message downstream. 398 </t> 399 <t> 400 RWS is used when at least one linear white space character is required to 401 separate field tokens. RWS &SHOULD; be produced as a single SP character. 402 Multiple RWS characters that occur within field-content &SHOULD; be 403 replaced with a single SP before interpreting the field value or 404 forwarding the message downstream. 405 </t> 406 <t> 407 BWS is used where the grammar allows optional whitespace for historical 408 reasons but senders &SHOULD-NOT; produce it in messages. HTTP/1.1 409 recipients &MUST; accept such bad optional whitespace and remove it before 392 410 interpreting the field value or forwarding the message downstream. 393 </t>394 <t>395 Historically, HTTP/1.1 header field values allow linear white space folding across396 multiple lines. However, this specification deprecates its use; senders &MUST-NOT;397 produce messages that include LWS folding (i.e., use the obs-fold rule), except398 within the message/http media type (<xref target="internet.media.type.message.http"/>).399 Receivers &SHOULD; still parse folded linear white space.400 </t>401 <t>402 This specification uses three rules to denote the use of linear white space;403 BWS ("Bad" White Space), OWS (Optional White Space), and RWS (Required White Space).404 </t>405 <t>406 "Bad" white space is allowed by the BNF, but senders &SHOULD-NOT; produce it in messages.407 Receivers &MUST; accept it in incoming messages.408 </t>409 <t>410 Required white space is used when at least one linear white space character411 is required to separate field tokens. In all such cases, a single SP character412 &SHOULD; be used.413 411 </t> 414 412 <t anchor="rule.whitespace"> … … 427 425 <x:ref>obs-fold</x:ref> = <x:ref>CRLF</x:ref> 428 426 </artwork></figure> 429 <t anchor="rule.TEXT">430 <x:anchor-alias value="TEXT"/>431 The TEXT rule is only used for descriptive field contents and values432 that are not intended to be interpreted by the message parser. Words433 of *TEXT &MAY; contain characters from character sets other than ISO-8859-1434 <xref target="ISO-8859-1"/> only when encoded according to the rules of435 <xref target="RFC2047"/>.436 </t>437 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TEXT"/>438 <x:ref>TEXT</x:ref> = %x20-7E / %x80-FF / <x:ref>OWS</x:ref>439 ; any <x:ref>OCTET</x:ref> except <x:ref>CTL</x:ref>s, but including <x:ref>OWS</x:ref>440 </artwork></figure>441 <t>442 A CRLF is allowed in the definition of TEXT only as part of a header443 field continuation. It is expected that the folding LWS will be444 replaced with a single SP before interpretation of the TEXT value.445 </t>446 427 <t anchor="rule.token.separators"> 447 428 <x:anchor-alias value="tchar"/> 448 429 <x:anchor-alias value="token"/> 449 Many HTTP/1.1 header field values consist of words separated by LWS430 Many HTTP/1.1 header field values consist of words separated by whitespace 450 431 or special characters. These special characters &MUST; be in a quoted 451 432 string to be used within a parameter value (as defined in … … 459 440 <x:ref>token</x:ref> = 1*<x:ref>tchar</x:ref> 460 441 </artwork></figure> 461 <t anchor="rule.comment">462 <x:anchor-alias value="comment"/>463 <x:anchor-alias value="ctext"/>464 Comments can be included in some HTTP header fields by surrounding465 the comment text with parentheses. Comments are only allowed in466 fields containing "comment" as part of their field value definition.467 In all other fields, parentheses are considered part of the field468 value.469 </t>470 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/>471 <x:ref>comment</x:ref> = "(" *( <x:ref>ctext</x:ref> / <x:ref>quoted-pair</x:ref> / <x:ref>comment</x:ref> ) ")"472 <x:ref>ctext</x:ref> = <any <x:ref>TEXT</x:ref> excluding "(" and ")">473 </artwork></figure>474 442 <t anchor="rule.quoted-string"> 475 443 <x:anchor-alias value="quoted-string"/> 476 444 <x:anchor-alias value="qdtext"/> 445 <x:anchor-alias value="obs-text"/> 477 446 A string of text is parsed as a single word if it is quoted using 478 447 double-quote marks. 479 448 </t> 480 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/> 449 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/><iref primary="true" item="Grammar" subitem="obs-text"/> 481 450 <x:ref>quoted-string</x:ref> = <x:ref>DQUOTE</x:ref> *(<x:ref>qdtext</x:ref> / <x:ref>quoted-pair</x:ref> ) <x:ref>DQUOTE</x:ref> 482 <x:ref>qdtext</x:ref> = <any <x:ref>TEXT</x:ref> excluding <x:ref>DQUOTE</x:ref> and "\"> 451 <x:ref>qdtext</x:ref> = *( <x:ref>OWS</x:ref> / %x21 / %x23-5B / %x5D-7E / <x:ref>obs-text</x:ref> ) 452 <x:ref>obs-text</x:ref> = %x80-FF 483 453 </artwork></figure> 484 454 <t anchor="rule.quoted-pair"> … … 564 534 </t> 565 535 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="URI-reference"/><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="uri-host"/> 566 <x:ref>URI</x:ref> = <URI, defined in <xref target="RFC3986" x:fmt="," x:sec="3"/> >567 <x:ref>URI-reference</x:ref> = <URI-reference, defined in <xref target="RFC3986" x:fmt="," x:sec="4.1"/> >568 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/> >569 <x:ref>relative-part</x:ref> = <relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/> >570 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/> >571 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/> >572 <x:ref>path-abempty</x:ref> = <path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/> >573 <x:ref>path-absolute</x:ref> = <path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/> >574 <x:ref>port</x:ref> = <port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/> >575 <x:ref>query</x:ref> = <query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/> >576 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/> >536 <x:ref>URI</x:ref> = <URI, defined in <xref target="RFC3986" x:fmt="," x:sec="3"/>> 537 <x:ref>URI-reference</x:ref> = <URI-reference, defined in <xref target="RFC3986" x:fmt="," x:sec="4.1"/>> 538 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>> 539 <x:ref>relative-part</x:ref> = <relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/>> 540 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>> 541 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>> 542 <x:ref>path-abempty</x:ref> = <path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>> 543 <x:ref>path-absolute</x:ref> = <path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>> 544 <x:ref>port</x:ref> = <port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>> 545 <x:ref>query</x:ref> = <query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>> 546 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>> 577 547 578 548 <x:ref>partial-URI</x:ref> = relative-part [ "?" query ] … … 906 876 abbreviation for time zone, and &MUST; be assumed when reading the 907 877 asctime format. HTTP-date is case sensitive and &MUST-NOT; include 908 additional LWSbeyond that specifically included as SP in the878 additional whitespace beyond that specifically included as SP in the 909 879 grammar. 910 880 </t> … … 1211 1181 extra CRLF. 1212 1182 </t> 1183 <t> 1184 Whitespace (WSP) &MUST-NOT; be sent between the start-line and the first 1185 header field. The presence of whitespace might be an attempt to trick a 1186 noncompliant implementation of HTTP into ignoring that field or processing 1187 the next line as a new request, either of which may result in security 1188 issues when implementations within the request chain interpret the 1189 same message differently. HTTP/1.1 servers &MUST; reject such a message 1190 with a 400 (Bad Request) response. 1191 </t> 1213 1192 </section> 1214 1193 … … 1219 1198 <x:anchor-alias value="message-header"/> 1220 1199 <t> 1221 HTTP header fields, which include general-header (<xref target="general.header.fields"/>), 1222 request-header (&request-header-fields;), response-header (&response-header-fields;), and 1223 entity-header (&entity-header-fields;) fields, follow the same generic format as 1224 that given in <xref target="RFC5322" x:fmt="of" x:sec="2.1"/>. Each header field consists 1225 of a name followed by a colon (":") and the field value. Field names 1226 are case-insensitive. The field value &MAY; be preceded by any amount 1227 of LWS, though a single SP is preferred. Header fields can be 1228 extended over multiple lines by preceding each extra line with at 1229 least one SP or HTAB. Applications ought to follow "common form", where 1230 one is known or indicated, when generating HTTP constructs, since 1231 there might exist some implementations that fail to accept anything 1232 beyond the common forms. 1200 HTTP header fields follow the same general format as Internet messages in 1201 <xref target="RFC5322" x:fmt="of" x:sec="2.1"/>. Each header field consists 1202 of a name followed by a colon (":"), optional whitespace, and the field 1203 value. Field names are case-insensitive. 1233 1204 </t> 1234 1205 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="message-header"/><iref primary="true" item="Grammar" subitem="field-name"/><iref primary="true" item="Grammar" subitem="field-value"/><iref primary="true" item="Grammar" subitem="field-content"/> 1235 <x:ref>message-header</x:ref> = <x:ref>field-name</x:ref> ":" [ <x:ref>field-value</x:ref> ]1206 <x:ref>message-header</x:ref> = <x:ref>field-name</x:ref> ":" OWS [ <x:ref>field-value</x:ref> ] OWS 1236 1207 <x:ref>field-name</x:ref> = <x:ref>token</x:ref> 1237 1208 <x:ref>field-value</x:ref> = *( <x:ref>field-content</x:ref> / <x:ref>OWS</x:ref> ) 1238 <x:ref>field-content</x:ref> = <field content> 1239 </artwork></figure> 1240 <t> 1241 <cref>whitespace between field-name and colon is an error and MUST NOT be accepted</cref> 1242 </t> 1243 <t> 1244 The field-content does not include any leading or trailing LWS: 1245 linear white space occurring before the first non-whitespace 1246 character of the field-value or after the last non-whitespace 1247 character of the field-value. Such leading or trailing LWS &MAY; be 1248 removed without changing the semantics of the field value. Any LWS 1249 that occurs between field-content &MAY; be replaced with a single SP 1250 before interpreting the field value or forwarding the message 1251 downstream. 1252 </t> 1209 <x:ref>field-content</x:ref> = *( <x:ref>WSP</x:ref> / <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref> ) 1210 </artwork></figure> 1211 <t> 1212 Historically, HTTP has allowed field-content with text in the ISO-8859-1 1213 <xref target="ISO-8859-1"/> character encoding (allowing other character sets 1214 through use of <xref target="RFC2047"/> encoding). In practice, most HTTP 1215 header field-values use only a subset of the US-ASCII charset 1216 <xref target="USASCII"/>. Newly defined header fields &SHOULD; constrain 1217 their field-values to US-ASCII characters. Recipients &SHOULD; treat other 1218 (obs-text) octets in field-content as opaque data. 1219 </t> 1220 <t> 1221 No whitespace is allowed between the header field-name and colon. For 1222 security reasons, any request message received containing such whitespace 1223 &MUST; be rejected with a response code of 400 (Bad Request) and any such 1224 whitespace in a response message &MUST; be removed. 1225 </t> 1226 <t> 1227 The field value &MAY; be preceded by optional white space; a single SP is 1228 preferred. The field-value does not include any leading or trailing white 1229 space: OWS occurring before the first non-whitespace character of the 1230 field-value or after the last non-whitespace character of the field-value 1231 is ignored and &MAY; be removed without changing the meaning of the header 1232 field. 1233 </t> 1234 <t> 1235 Historically, HTTP header field values could be extended over multiple 1236 lines by preceding each extra line with at least one space or horizontal 1237 tab character (line folding). This specification deprecates such line 1238 folding except within the message/http media type 1239 (<xref target="internet.media.type.message.http"/>). 1240 HTTP/1.1 senders &MUST-NOT; produce messages that include line folding 1241 (i.e., that contain any field-content that matches the obs-fold rule) unless 1242 the message is intended for packaging within the message/http media type. 1243 HTTP/1.1 recipients &SHOULD; accept line folding and replace any embedded 1244 obs-fold whitespace with a single SP prior to interpreting the field value 1245 or forwarding the message downstream. 1246 </t> 1247 <t anchor="rule.comment"> 1248 <x:anchor-alias value="comment"/> 1249 <x:anchor-alias value="ctext"/> 1250 Comments can be included in some HTTP header fields by surrounding 1251 the comment text with parentheses. Comments are only allowed in 1252 fields containing "comment" as part of their field value definition. 1253 In all other fields, parentheses are considered part of the field 1254 value. 1255 </t> 1256 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/> 1257 <x:ref>comment</x:ref> = "(" *( <x:ref>ctext</x:ref> / <x:ref>quoted-pair</x:ref> / <x:ref>comment</x:ref> ) ")" 1258 <x:ref>ctext</x:ref> = *( <x:ref>OWS</x:ref> / %x21-27 / %x2A-7E / <x:ref>obs-text</x:ref> ) 1259 </artwork></figure> 1253 1260 <t> 1254 1261 The order in which header fields with differing field names are … … 1692 1699 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Status-Code"/><iref primary="true" item="Grammar" subitem="extension-code"/><iref primary="true" item="Grammar" subitem="Reason-Phrase"/> 1693 1700 <x:ref>Status-Code</x:ref> = 3<x:ref>DIGIT</x:ref> 1694 <x:ref>Reason-Phrase</x:ref> = * <<x:ref>TEXT</x:ref>, excluding <x:ref>CR</x:ref>, <x:ref>LF</x:ref>>1701 <x:ref>Reason-Phrase</x:ref> = *( <x:ref>WSP</x:ref> / <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref> ) 1695 1702 </artwork></figure> 1696 1703 </section> … … 3865 3872 Clients &SHOULD; be tolerant in parsing the Status-Line and servers 3866 3873 tolerant when parsing the Request-Line. In particular, they &SHOULD; 3867 accept any amount of SP or HTABcharacters between fields, even though3874 accept any amount of WSP characters between fields, even though 3868 3875 only a single SP is required. 3869 3876 </t> … … 4077 4084 Rules about implicit linear white space between certain grammar productions 4078 4085 have been removed; now it's only allowed when specifically pointed out 4079 in the ABNF. 4080 The CHAR rule does not allow the NUL character anymore (this affects 4081 the comment and quoted-string rules). Furthermore, the quoted-pair 4082 rule does not allow escaping NUL, CR or LF anymore. 4086 in the ABNF. The NUL character is no longer allowed in comment and quoted-string 4087 text. The quoted-pair rule no longer allows escaping NUL, CR or LF. 4083 4088 (<xref target="basic.rules"/>) 4084 4089 </t> … … 4463 4468 </t> 4464 4469 <t> 4465 Use names of RFC4234 core rules DQUOTE and HTAB,4470 Use names of RFC4234 core rules DQUOTE and WSP, 4466 4471 fix broken ABNF for chunk-data 4467 4472 (work in progress on <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>) … … 4510 4515 </t> 4511 4516 <t> 4512 Synchronize core rules with RFC5234 (this includes a change to CHAR 4513 which now excludes NUL). 4517 Synchronize core rules with RFC5234. 4514 4518 </t> 4515 4519 <t>
Note: See TracChangeset
for help on using the changeset viewer.