Changeset 1770 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 14/07/12 12:41:41 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1768 r1770 449 449 } 450 450 @bottom-center { 451 content: "Expires January 1 4, 2013";451 content: "Expires January 15, 2013"; 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="2012-07-1 3">493 <meta name="dct.issued" scheme="ISO8601" content="2012-07-14"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: January 1 4, 2013</td>525 <td class="left">Expires: January 15, 2013</td> 526 526 <td class="right">greenbytes</td> 527 527 </tr> 528 528 <tr> 529 529 <td class="left"></td> 530 <td class="right">July 1 3, 2012</td>530 <td class="right">July 14, 2012</td> 531 531 </tr> 532 532 </tbody> … … 560 560 in progress”. 561 561 </p> 562 <p>This Internet-Draft will expire on January 1 4, 2013.</p>562 <p>This Internet-Draft will expire on January 15, 2013.</p> 563 563 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 564 564 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 965 965 <p id="rfc.section.2.6.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 966 966 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 967 or caches, depending on what behavior is being constrained by the requirement. The verb "generate" is used instead of "send" 968 where a requirement differentiates between creating a protocol element and merely forwarding a received element downstream. 969 </p> 970 <p id="rfc.section.2.6.p.2">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 971 in HTTP. 972 </p> 973 <p id="rfc.section.2.6.p.3">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 967 or caches, depending on what behavior is being constrained by the requirement. 968 </p> 969 <p id="rfc.section.2.6.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely 970 forwarding a received element downstream. 971 </p> 972 <p id="rfc.section.2.6.p.3">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 973 in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 974 </p> 975 <p id="rfc.section.2.6.p.4">In addition to the prose requirements placed upon them, senders <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 974 976 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 975 977 to the recipient's role. 976 978 </p> 977 <p id="rfc.section.2.6.p. 4">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 mechanisms979 <p id="rfc.section.2.6.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 978 980 except when they have a direct impact on security, since different applications of the protocol require different error handling 979 981 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
Note: See TracChangeset
for help on using the changeset viewer.