Changeset 1770 for draft-ietf-httpbis/latest/p4-conditional.html
- Timestamp:
- 14/07/12 12:41:41 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r1764 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 { … … 490 490 <meta name="dct.creator" content="Reschke, J. F."> 491 491 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 492 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 3">492 <meta name="dct.issued" scheme="ISO8601" content="2012-07-14"> 493 493 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 494 494 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests."> … … 516 516 </tr> 517 517 <tr> 518 <td class="left">Expires: January 1 4, 2013</td>518 <td class="left">Expires: January 15, 2013</td> 519 519 <td class="right">J. Reschke, Editor</td> 520 520 </tr> … … 525 525 <tr> 526 526 <td class="left"></td> 527 <td class="right">July 1 3, 2012</td>527 <td class="right">July 14, 2012</td> 528 528 </tr> 529 529 </tbody> … … 554 554 in progress”. 555 555 </p> 556 <p>This Internet-Draft will expire on January 1 4, 2013.</p>556 <p>This Internet-Draft will expire on January 15, 2013.</p> 557 557 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 558 558 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 649 649 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 650 650 </p> 651 <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 652 Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms. 653 </p> 654 <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that 655 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 656 </p> 657 <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 658 </p> 659 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling 660 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 661 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 662 the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery 663 could lead to dangerous consequences. 651 <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 652 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 653 or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms. 654 </p> 655 <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely 656 forwarding a received element downstream. 657 </p> 658 <p id="rfc.section.1.1.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 659 in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 660 </p> 661 <p id="rfc.section.1.1.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). 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 662 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 663 to the recipient's role. 664 </p> 665 <p id="rfc.section.1.1.p.6">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 666 except when they have a direct impact on security, since different applications of the protocol require different error handling 667 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 668 to be dangerous. 664 669 </p> 665 670 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2>
Note: See TracChangeset
for help on using the changeset viewer.