Changeset 368 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 13/11/08 19:27:20 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r367 r368 418 418 <section title="Notational Conventions and Generic Grammar" anchor="notation"> 419 419 420 <section title="ABNF Extensions" anchor="notation.abnf"> 421 <t> 422 Two extensions to the ABNF rules of <xref target="RFC5234"/> are used to 423 improve readability.<cref>The current plan is to remove these extensions prior 424 to the last call draft.</cref> 425 </t> 426 427 <section title="#rule"> 420 <section title="ABNF Extension: #rule" anchor="notation.abnf"> 421 <t> 422 One extension to the ABNF rules of <xref target="RFC5234"/> is used to 423 improve readability. 424 </t> 428 425 <t> 429 426 A construct "#" is defined, similar to "*", for defining lists of 430 427 elements. The full form is "<n>#<m>element" indicating at least 431 428 <n> and at most <m> elements, each separated by one or more commas 432 (",") and &OPTIONAL; linear white space ( LWS). This makes the usual429 (",") and &OPTIONAL; linear white space (OWS). This makes the usual 433 430 form of lists very easy; a rule such as 434 431 <figure><artwork type="example"> 435 ( *<x:ref> LWS</x:ref> element *( *<x:ref>LWS</x:ref> "," *<x:ref>LWS</x:ref> element ))</artwork></figure>432 ( *<x:ref>OWS</x:ref> element *( *<x:ref>OWS</x:ref> "," *<x:ref>OWS</x:ref> element ))</artwork></figure> 436 433 </t> 437 434 <t> … … 450 447 two. 451 448 </t> 452 </section>453 454 <section title="implied *LWS" anchor="implied.LWS">455 <iref item="implied *LWS" primary="true"/>456 <t>457 The grammar described by this specification is word-based. Except458 where noted otherwise, linear white space (LWS) can be included459 between any two adjacent words (token or quoted-string), and460 between adjacent words and separators, without changing the461 interpretation of a field. At least one delimiter (LWS and/or462 separators) &MUST; exist between any two tokens (for the definition463 of "token" below), since they would otherwise be interpreted as a464 single token.465 </t>466 </section>467 449 </section> 468 450 … … 500 482 </t> 501 483 <t anchor="rule.LWS"> 502 <x:anchor-alias value="LWS"/> 503 HTTP/1.1 header field values can be folded onto multiple lines if the 504 continuation line begins with a space or horizontal tab. All linear 505 white space, including folding, has the same semantics as SP. A 506 recipient &MAY; replace any linear white space with a single SP before 484 All linear white space (LWS) in header field-values has the same semantics as SP. A 485 recipient &MAY; replace any such linear white space with a single SP before 507 486 interpreting the field value or forwarding the message downstream. 508 487 </t> 509 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="LWS"/> 510 <x:ref>LWS</x:ref> = [<x:ref>CRLF</x:ref>] 1*<x:ref>WSP</x:ref> 511 </artwork></figure> 488 <t> 489 Historically, HTTP/1.1 header field values allow linear white space folding across 490 multiple lines. However, this specification deprecates its use; senders MUST NOT 491 produce messages that include LWS folding (i.e., use the obs-fold rule), except 492 within the message/http media type <xref target="internet.media.type.message.http"/>. 493 Receivers SHOULD still parse folded linear white space. 494 </t> 495 <t> 496 This specification uses three rules to denote the use of linear white space; 497 BWS ("Bad" White Space), OWS (Optional White Space), and RWS (Required White Space). 498 </t> 499 <t> 500 "Bad" white space is allowed by the BNF, but senders SHOULD NOT produce it in messages. 501 Receivers MUST accept it in incoming messages. 502 </t> 503 512 504 <t anchor="rule.whitespace"> 513 505 <x:anchor-alias value="BWS"/>
Note: See TracChangeset
for help on using the changeset viewer.