Ignore:
Timestamp:
Jan 11, 2008, 9:09:10 PM (12 years ago)
Author:
fielding@…
Message:

editorial: make introductions more active and consistent

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p4-conditional.html

    r160 r163  
    521521      </ul>
    522522      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    523       <p id="rfc.section.1.p.1">This document defines aspects of HTTP related to conditional request messages based on time stamps and entity-tags. Right
    524          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> with only minor changes. This introduction will be revised in the next draft.
     523      <p id="rfc.section.1.p.1">This document defines HTTP/1.1 response metadata for indicating potential changes to payload content, including modification
     524         time stamps and opaque entity-tags, and the HTTP conditional request mechanisms that allow preconditions to be placed on a
     525         request method. Conditional GET requests allow for efficient cache updates. Other conditional request methods are used to
     526         protect against overwriting or misunderstanding the state of a resource that has been changed unbeknownst to the requesting
     527         client.
     528      </p>
     529      <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
     530         errata changes. The next draft will reorganize the sections to better reflect the content. In particular, the sections on
     531         resource metadata will be discussed first and then followed by each conditional request-header, concluding with a definition
     532         of precedence and the expectation of ordering strong validator checks before weak validator checks. It is likely that more
     533         content from <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> will migrate to this part, where appropriate. The current mess reflects how widely dispersed these topics and associated requirements
     534         had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
    525535      </p>
    526536      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
     
    756766         header <em class="bcp14">MUST</em> be ignored.
    757767      </p>
    758       <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 15.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.
     768      <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 15.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.
    759769      </p>
    760770      <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.
     
    837847         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&nbsp;5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
    838848      </p>
    839       <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 15.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.
     849      <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 15.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.
    840850      </p>
    841851      <p id="rfc.section.6.4.p.9">Examples:</p>
     
    10641074                     </ul>
    10651075                  </li>
    1066                   <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<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.1</b></a><ul class="ind">
    1067                         <li class="indline1"><em>Section 15.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">6.2</a>, <a class="iref" href="#rfc.xref.Part6.2">6.4</a></li>
     1076                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">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.1</b></a><ul class="ind">
     1077                        <li class="indline1"><em>Section 15.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.2">6.2</a>, <a class="iref" href="#rfc.xref.Part6.3">6.4</a></li>
    10681078                     </ul>
    10691079                  </li>
Note: See TracChangeset for help on using the changeset viewer.