Changeset 115 for draft-ietf-httpbis/latest/p4-conditional.html
- Timestamp:
- 30/12/07 14:56:05 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r113 r115 343 343 <link rel="Chapter" href="#rfc.section.10" title="10 References"> 344 344 <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A"> 345 <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B"> 345 346 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.353, 2007/12/11 23:20:44, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 346 347 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> … … 471 472 </p> 472 473 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> 473 <p>This version of the HTTP specification contains only minimal editorial changes from <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> (abstract, introductory paragraph, and authors' addresses). All other changes are due to partitioning the original into seven474 mostly independent parts. The intent is for readers of future drafts to able to use draft 00 as the basis for comparison when475 the WG makes later changes to the specification text. This draft will shortly be followed by draft 01 (containing the first476 round of changes that have already been agreed to on the mailing list). There is no point in reviewing this draft other than477 to verify that the partitioning has been done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke will be the editors478 after draft 00 is submitted.479 </p>480 474 <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues 481 475 list is at <<a href="http://www.tools.ietf.org/wg/httpbis/trac/report/11">http://www.tools.ietf.org/wg/httpbis/trac/report/11</a>> and related documents (including fancy diffs) can be found at <<a href="http://www.tools.ietf.org/wg/httpbis/">http://www.tools.ietf.org/wg/httpbis/</a>>. … … 514 508 </ul> 515 509 </li> 510 <li class="tocline0">B. <a href="#rfc.section.B">Change Log (to be removed by RFC Editor before publication)</a><ul class="toc"> 511 <li class="tocline1">B.1 <a href="#rfc.section.B.1">Since RFC2616</a></li> 512 <li class="tocline1">B.2 <a href="#rfc.section.B.2">Since draft-ietf-httpbis-p4-conditional-00</a></li> 513 </ul> 514 </li> 516 515 <li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li> 517 516 <li class="tocline0"><a href="#rfc.index">Index</a></li> … … 519 518 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 520 519 <p id="rfc.section.1.p.1">This document will define aspects of HTTP related to conditional request messages based on time stamps and entity-tags. Right 521 now it only includes the extracted relevant sections of <a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616. 2">[RFC2616]</cite> without edit.520 now it only includes the extracted relevant sections of <a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">[RFC2616]</cite> without edit. 522 521 </p> 523 522 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> … … 563 562 </li> 564 563 </ul> 565 <p id="rfc.section.3.1.p.4">If the conditional GET used a strong cache validator (see <a href="# Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>), the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response <em class="bcp14">MUST NOT</em> include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.564 <p id="rfc.section.3.1.p.4">If the conditional GET used a strong cache validator (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>), the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response <em class="bcp14">MUST NOT</em> include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. 566 565 </p> 567 566 <p id="rfc.section.3.1.p.5">If a 304 response indicates an entity not currently cached, then the cache <em class="bcp14">MUST</em> disregard the response and repeat the request without the conditional. … … 723 722 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.etag" href="#header.etag">ETag</a></h2> 724 723 <p id="rfc.section.6.1.p.1">The ETag response-header field provides the current value of the entity tag for the requested variant. The headers used with 725 entity tags are described in Sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">6.2</a> , <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">6.4</a> and<a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The entity tag <em class="bcp14">MAY</em> be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>).724 entity tags are described in Sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">6.2</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">6.4</a> of this document, and in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The entity tag <em class="bcp14">MAY</em> be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>). 726 725 </p> 727 726 <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.4"></span> ETag = "ETag" ":" entity-tag … … 752 751 header <em class="bcp14">MUST</em> be ignored. 753 752 </p> 754 <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6. 2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.753 <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist. 755 754 </p> 756 755 <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource. … … 833 832 If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity Tags and Last-Modified Dates">Section 5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.) 834 833 </p> 835 <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6. 3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.834 <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations. 836 835 </p> 837 836 <p id="rfc.section.6.4.p.9">Examples:</p> … … 943 942 <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 944 943 <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 944 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> Change Log (to be removed by RFC Editor before publication) 945 </h1> 946 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> Since RFC2616 947 </h2> 948 <p id="rfc.section.B.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 949 </p> 950 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Since draft-ietf-httpbis-p4-conditional-00 951 </h2> 952 <p id="rfc.section.B.2.p.1">TBD.</p> 945 953 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 946 954 <p>Copyright © The IETF Trust (2007).</p> … … 1037 1045 </ul> 1038 1046 </li> 1039 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1"> 3.1</a>, <a class="iref" href="#rfc.xref.Part6.2">6.2</a>, <a class="iref" href="#rfc.xref.Part6.3">6.4</a>, <a class="iref" href="#Part6"><b>10</b></a><ul class="ind">1040 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part6. 2">6.2</a>, <a class="iref" href="#rfc.xref.Part6.3">6.4</a></li>1047 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">6.2</a>, <a class="iref" href="#rfc.xref.Part6.2">6.4</a>, <a class="iref" href="#Part6"><b>10</b></a><ul class="ind"> 1048 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part6.1">6.2</a>, <a class="iref" href="#rfc.xref.Part6.2">6.4</a></li> 1041 1049 </ul> 1042 1050 </li> … … 1049 1057 </li> 1050 1058 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>10</b></a></li> 1051 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1"> §</a>, <a class="iref" href="#rfc.xref.RFC2616.2">1</a>, <a class="iref" href="#RFC2616"><b>10</b></a></li>1059 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b>10</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">B.1</a></li> 1052 1060 </ul> 1053 1061 </li>
Note: See TracChangeset
for help on using the changeset viewer.