Changeset 2332
- Timestamp:
- 31/07/13 17:43:09 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2319 r2332 449 449 } 450 450 @bottom-center { 451 content: "Expires January 29, 2014";451 content: "Expires February 1, 2014"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2013-07- 28">493 <meta name="dct.issued" scheme="ISO8601" content="2013-07-31"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 520 520 <tr> 521 521 <td class="left">Intended status: Standards Track</td> 522 <td class="right">July 28, 2013</td>522 <td class="right">July 31, 2013</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: January 29, 2014</td>525 <td class="left">Expires: February 1, 2014</td> 526 526 <td class="right"></td> 527 527 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on January 29, 2014.</p>553 <p>This Internet-Draft will expire on February 1, 2014.</p> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 955 955 in HTTP. 956 956 </p> 957 <p id="rfc.section.2.5.p.4">Conformance applies to both the syntax and semantics of HTTP protocol elements. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that convey a meaning that is known by that sender to be false. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable 958 to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable 959 to the recipient's role. 960 </p> 961 <p id="rfc.section.2.5.p.5">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 957 <p id="rfc.section.2.5.p.4">Conformance includes both the syntax and semantics of HTTP protocol elements. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that convey a meaning that is known by that sender to be false. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the corresponding ABNF rules. Within a given message, 958 a sender <em class="bcp14">MUST NOT</em> generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., 959 a role that the sender does not have for that message). 960 </p> 961 <p id="rfc.section.2.5.p.5">When a received protocol element is parsed, the recipient <em class="bcp14">MUST</em> be able to parse any value of reasonable length that is applicable to the recipient's role and matches the grammar defined 962 by the corresponding ABNF rules. Note, however, that some received protocol elements might not be parsed. For example, an 963 intermediary forwarding a message might parse a header-field into generic field-name and field-value components, but then 964 forward the header field without further parsing inside the field-value. 965 </p> 966 <p id="rfc.section.2.5.p.6">HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate 967 will vary widely, depending on the deployment context and purpose of the implementation. Hence, interoperability between senders 968 and recipients depends on shared expectations regarding what is a reasonable length for each protocol element. Furthermore, 969 what is commonly understood to be a reasonable length for some protocol elements has changed over the course of the past two 970 decades of HTTP use, and is expected to continue changing in the future. 971 </p> 972 <p id="rfc.section.2.5.p.7">At a minimum, a recipient <em class="bcp14">MUST</em> be able to parse and process protocol element lengths that are at least as long as the values that it generates for those 973 same protocol elements in other messages. For example, an origin server that publishes very long URI references to its own 974 resources needs to be able to parse and process those same references when received as a request target. 975 </p> 976 <p id="rfc.section.2.5.p.8">A recipient <em class="bcp14">MUST</em> interpret a received protocol element according to the semantics defined for it by this specification, including extensions 977 to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly 978 implements what is implied by those semantics. For example, an origin server might disregard the contents of a received <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> header field if inspection of the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> header field indicates a specific implementation version that is known to fail on receipt of certain content codings. 979 </p> 980 <p id="rfc.section.2.5.p.9">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 962 981 except when they have a direct impact on security, since different applications of the protocol require different error handling 963 982 strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery -
draft-ietf-httpbis/latest/p1-messaging.xml
r2319 r2332 620 620 </t> 621 621 <t> 622 Conformance applies toboth the syntax and semantics of HTTP protocol622 Conformance includes both the syntax and semantics of HTTP protocol 623 623 elements. A sender &MUST-NOT; generate protocol elements that convey a 624 624 meaning that is known by that sender to be false. A sender &MUST-NOT; 625 625 generate protocol elements that do not match the grammar defined by the 626 ABNF rules for those protocol elements that are applicable to the sender's 627 role. If a received protocol element is processed, the recipient &MUST; be 628 able to parse any value that would match the ABNF rules for that protocol 629 element, excluding only those rules not applicable to the recipient's role. 626 corresponding ABNF rules. Within a given message, a sender &MUST-NOT; 627 generate protocol elements or syntax alternatives that are only allowed to 628 be generated by participants in other roles (i.e., a role that the sender 629 does not have for that message). 630 </t> 631 <t> 632 When a received protocol element is parsed, the recipient &MUST; be able to 633 parse any value of reasonable length that is applicable to the recipient's 634 role and matches the grammar defined by the corresponding ABNF rules. 635 Note, however, that some received protocol elements might not be parsed. 636 For example, an intermediary forwarding a message might parse a 637 header-field into generic field-name and field-value components, but then 638 forward the header field without further parsing inside the field-value. 639 </t> 640 <t> 641 HTTP does not have specific length limitations for many of its protocol 642 elements because the lengths that might be appropriate will vary widely, 643 depending on the deployment context and purpose of the implementation. 644 Hence, interoperability between senders and recipients depends on shared 645 expectations regarding what is a reasonable length for each protocol 646 element. Furthermore, what is commonly understood to be a reasonable length 647 for some protocol elements has changed over the course of the past two 648 decades of HTTP use, and is expected to continue changing in the future. 649 </t> 650 <t> 651 At a minimum, a recipient &MUST; be able to parse and process protocol 652 element lengths that are at least as long as the values that it generates 653 for those same protocol elements in other messages. For example, an origin 654 server that publishes very long URI references to its own resources needs 655 to be able to parse and process those same references when received as a 656 request target. 657 </t> 658 <t> 659 A recipient &MUST; interpret a received protocol element according to the 660 semantics defined for it by this specification, including extensions to 661 this specification, unless the recipient has determined (through experience 662 or configuration) that the sender incorrectly implements what is implied by 663 those semantics. 664 For example, an origin server might disregard the contents of a received 665 <x:ref>Accept-Encoding</x:ref> header field if inspection of the 666 <x:ref>User-Agent</x:ref> header field indicates a specific implementation 667 version that is known to fail on receipt of certain content codings. 630 668 </t> 631 669 <t> … … 4088 4126 <x:defines>502 (Bad Gateway)</x:defines> 4089 4127 <x:defines>505 (HTTP Version Not Supported)</x:defines> 4128 <x:defines>Accept-Encoding</x:defines> 4090 4129 <x:defines>Allow</x:defines> 4091 4130 <x:defines>Content-Encoding</x:defines>
Note: See TracChangeset
for help on using the changeset viewer.