Ignore:
Timestamp:
11/01/13 10:24:02 (10 years ago)
Author:
fielding@…
Message:

(editorial) the final answer on representation; addresses #315

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r2111 r2112  
    847847         of representation data.
    848848      </p>
    849       <p id="rfc.section.3.p.3">We use the term "<dfn>selected representation</dfn>" to refer to the representation of the <a href="#resources" class="smpl">target resource</a> in a <a href="#status.200" class="smpl">200 (OK)</a> response to <a href="#GET" class="smpl">GET</a>, or the representation that would have been selected in a successful response if the request had used the method <a href="#GET" class="smpl">GET</a> and excluded any conditional request header fields.
     849      <p id="rfc.section.3.p.3">An origin server might be provided with, or capable of generating, multiple representations that are each intended to reflect
     850         the current state of a <a href="#resources" class="smpl">target resource</a>. In such cases, some algorithm is used by the origin server to select one of those representations as most applicable to
     851         a given request, usually based on <a href="#content.negotiation" class="smpl">content negotiation</a>. We refer to that one representation as the "<dfn>selected representation</dfn>" and use its particular data and metadata for evaluating conditional requests <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> and constructing the payload for <a href="#status.200" class="smpl">200 (OK)</a> and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>).
    850852      </p>
    851853      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="representation.metadata" href="#representation.metadata">Representation Metadata</a></h2>
    … …  
    10751077         <li>If the request is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload's identifier is the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    10761078         </li>
    1077          <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is a potentially modified representation of the <a href="#resources" class="smpl">target resource</a>; as such, the effective request URI might only act as an identifier for the payload's representation when a request is made
    1078             via the same chain of intermediaries.
     1079         <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is intended to be a representation of the <a href="#resources" class="smpl">target resource</a> that has been modified by an intermediary.
    10791080         </li>
    10801081         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to the same URI as the effective request URI, the payload's identifier is
    … …  
    10971098      </p>
    10981099      <p id="rfc.section.3.1.4.2.p.4">If Content-Location is included in a <a href="#status.2xx" class="smpl">2xx (Successful)</a> response message and its value refers (after conversion to absolute form) to a URI that is the same as the effective request
    1099          URI, then the response payload <em class="bcp14">SHOULD</em> be considered a current representation of that resource. For a GET or HEAD request, this is the same as the default semantics
    1100          when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's
    1101          response contains the new representation of that resource, thereby distinguishing it from representations that might only
    1102          report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the
    1103          need for a subsequent GET request.
     1100         URI, then the recipient <em class="bcp14">MAY</em> consider the payload to be a current representation of that resource at the time indicated by the message origination date.
     1101         For a GET or HEAD request, this is the same as the default semantics when no Content-Location is provided by the server. For
     1102         a state-changing request like PUT or POST, it implies that the server's response contains the new representation of that resource,
     1103         thereby distinguishing it from representations that might only report about the action (e.g., "It worked!"). This allows authoring
     1104         applications to update their local copies without the need for a subsequent GET request.
    11041105      </p>
    11051106      <p id="rfc.section.3.1.4.2.p.5">If Content-Location is included in a <a href="#status.2xx" class="smpl">2xx (Successful)</a> response message and its field-value refers to a URI that differs from the effective request URI, then the origin server claims
    … …  
    11491150      </p>
    11501151      <p id="rfc.section.3.3.p.3">In a response, the payload's purpose is defined by both the request method and the response status code. For example, the
    1151          payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>) represents the current state of the <a href="#resources" class="smpl">target resource</a>, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.1.1.2</a>), whereas the payload of the same status code in a response to POST might represent either the processing result or the new
     1152         payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.2" title="GET">Section&nbsp;4.3.1</a>) represents the current state of the <a href="#resources" class="smpl">target resource</a>, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.1.1.2</a>), whereas the payload of the same status code in a response to POST might represent either the processing result or the new
    11521153         state of the target resource after applying the processing. Response messages with an error status code usually contain a
    11531154         payload that represents the error condition, such that it describes the error state and what next steps are suggested for
    … …  
    12801281                  <td class="left">GET</td>
    12811282                  <td class="left">Transfer a current representation of the target resource.</td>
    1282                   <td class="left"><a href="#GET" id="rfc.xref.GET.2" title="GET">4.3.1</a></td>
     1283                  <td class="left"><a href="#GET" id="rfc.xref.GET.3" title="GET">4.3.1</a></td>
    12831284               </tr>
    12841285               <tr>
    … …  
    13891390         of the process, unless that text happens to be the output of the process.
    13901391      </p>
    1391       <p id="rfc.section.4.3.1.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional
     1392      <p id="rfc.section.4.3.1.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional
    13921393         header field(s). The conditional GET request is intended to reduce unnecessary network usage by allowing cached representations
    13931394         to be refreshed without requiring multiple requests or transferring data already held by the client.
    … …  
    17481749      </p>
    17491750      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="request.conditionals" href="#request.conditionals">Conditionals</a></h2>
    1750       <p id="rfc.section.5.2.p.1">Conditionals are request header fields that indicate a precondition to be tested before applying the method semantics to the <a href="#resources" class="smpl">target resource</a>. Each precondition is based on metadata that is expected to change if the selected representation of the target resource
    1751          is changed. The HTTP/1.1 conditional request mechanisms are defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
     1751      <p id="rfc.section.5.2.p.1">Conditionals are request header fields that indicate a precondition to be tested before applying the method semantics to the <a href="#resources" class="smpl">target resource</a>. Each precondition is based on metadata that is expected to change if the <a href="#representations" class="smpl">selected representation</a> is changed. The HTTP/1.1 conditional request mechanisms are defined in <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    17521752      </p>
    17531753      <div id="rfc.table.u.4">
    … …  
    17621762               <tr>
    17631763                  <td class="left">If-Match</td>
    1764                   <td class="left"><a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
     1764                  <td class="left"><a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    17651765               </tr>
    17661766               <tr>
    17671767                  <td class="left">If-None-Match</td>
    1768                   <td class="left"><a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
     1768                  <td class="left"><a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    17691769               </tr>
    17701770               <tr>
    17711771                  <td class="left">If-Modified-Since</td>
    1772                   <td class="left"><a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
     1772                  <td class="left"><a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    17731773               </tr>
    17741774               <tr>
    17751775                  <td class="left">If-Unmodified-Since</td>
    1776                   <td class="left"><a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
     1776                  <td class="left"><a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    17771777               </tr>
    17781778               <tr>
    … …  
    21662166      </ul>
    21672167      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2>
    2168       <p id="rfc.section.6.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
     2168      <p id="rfc.section.6.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
    21692169         protocol.
    21702170      </p>
    … …  
    22472247                  <td class="left">304</td>
    22482248                  <td class="left">Not Modified</td>
    2249                   <td id="status.304" class="left"><a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
     2249                  <td id="status.304" class="left"><a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    22502250               </tr>
    22512251               <tr>
    … …  
    23222322                  <td class="left">412</td>
    23232323                  <td class="left">Precondition Failed</td>
    2324                   <td id="status.412" class="left"><a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
     2324                  <td id="status.412" class="left"><a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    23252325               </tr>
    23262326               <tr>
    … …  
    24272427      <div id="rfc.iref.73"></div>
    24282428      <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a id="status.200" href="#status.200">200 OK</a></h3>
    2429       <p id="rfc.section.6.3.1.p.1">The <dfn>200 (OK)</dfn> status code indicates that the request has succeeded. The meaning of a payload sent in the response depends on the request
    2430          method. For the methods defined by this specification, the payload can be summarized as:
     2429      <p id="rfc.section.6.3.1.p.1">The <dfn>200 (OK)</dfn> status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method. For
     2430         the methods defined by this specification, the intended meaning of the payload can be summarized as:
    24312431      </p>
    24322432      <dl>
    … …  
    26052605         can be separately identified, bookmarked, and cached independent of the original request.
    26062606      </p>
    2607       <p id="rfc.section.6.4.4.p.3">A 303 response to a GET request indicates that the <a href="#resources" class="smpl">target resource</a> does not have a representation of its own that can be transferred by the server over HTTP. The <a href="#header.location" class="smpl">Location</a> field value refers to a resource that is descriptive of the target resource, such that the follow-on representation might
    2608          be useful to recipients without implying that it adequately represents the target resource. Note that answers to the questions
    2609          of what can be represented, what representations are adequate, and what might be a useful description are outside the scope
    2610          of HTTP.
     2607      <p id="rfc.section.6.4.4.p.3">A 303 response to a GET request indicates that the origin server does not have a representation of the <a href="#resources" class="smpl">target resource</a> that can be transferred by the server over HTTP. However, the <a href="#header.location" class="smpl">Location</a> field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that
     2608         other resource might result in a representation that is useful to recipients without implying that it represents the original
     2609         target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what
     2610         might be a useful description are outside the scope of HTTP.
    26112611      </p>
    26122612      <p id="rfc.section.6.4.4.p.4">Except for responses to a HEAD request, the representation of a 303 response ought to contain a short hypertext note with
    … …  
    30563056      </p>
    30573057      <p id="rfc.section.7.2.p.3">For example, an ETag header field in a 201 response communicates the entity-tag of the newly created resource's representation,
    3058          so that it can be used in later conditional requests to prevent the "lost update" problem <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
     3058         so that it can be used in later conditional requests to prevent the "lost update" problem <a href="#Part4" id="rfc.xref.Part4.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    30593059      </p>
    30603060      <div id="rfc.table.u.11">
    … …  
    30693069               <tr>
    30703070                  <td class="left">ETag</td>
    3071                   <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
     3071                  <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    30723072               </tr>
    30733073               <tr>
    30743074                  <td class="left">Last-Modified</td>
    3075                   <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
     3075                  <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    30763076               </tr>
    30773077            </tbody>
    … …  
    31883188         makes to header field or status code semantics. If the new method is cacheable, its definition ought to describe how, and
    31893189         under what conditions, a cache can store a response and use it to satisfy a subsequent request. If the new method can be made
    3190          conditional (<a href="#Part4" id="rfc.xref.Part4.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), the definition ought to describe how to respond when the condition is false. Likewise, if the new method might have some
     3190         conditional (<a href="#Part4" id="rfc.xref.Part4.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), the definition ought to describe how to respond when the condition is false. Likewise, if the new method might have some
    31913191         use for partial response semantics (<a href="#Part5" id="rfc.xref.Part5.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>), it ought to document this too.
    31923192      </p>
    … …  
    32233223                  <td class="left">yes</td>
    32243224                  <td class="left">yes</td>
    3225                   <td class="left"> <a href="#GET" id="rfc.xref.GET.3" title="GET">Section&nbsp;4.3.1</a>
     3225                  <td class="left"> <a href="#GET" id="rfc.xref.GET.4" title="GET">Section&nbsp;4.3.1</a>
    32263226                  </td>
    32273227               </tr>
    … …  
    41704170      </p>
    41714171      <p id="rfc.section.B.p.6">The Content-MD5 header field has been removed because it was inconsistently implemented with respect to partial responses.</p>
    4172       <p id="rfc.section.B.p.7">To be consistent with the method-neutral parsing algorithm of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET (<a href="#GET" id="rfc.xref.GET.4" title="GET">Section&nbsp;4.3.1</a>).
     4172      <p id="rfc.section.B.p.7">To be consistent with the method-neutral parsing algorithm of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET (<a href="#GET" id="rfc.xref.GET.5" title="GET">Section&nbsp;4.3.1</a>).
    41734173      </p>
    41744174      <p id="rfc.section.B.p.8">Servers are no longer required to handle all Content-* header fields and use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> has been explicitly banned in PUT requests (<a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section&nbsp;4.3.4</a>).
    … …  
    45084508            </li>
    45094509            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    4510                   <li>GET method&nbsp;&nbsp;<a href="#rfc.extref.g.1">3</a>, <a href="#rfc.extref.g.2">3</a>, <a href="#rfc.xref.GET.1">3.3</a>, <a href="#rfc.xref.GET.2">4.1</a>, <a href="#rfc.iref.g.16"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.3">8.1.3</a>, <a href="#rfc.xref.GET.4">B</a></li>
     4510                  <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.xref.GET.2">3.3</a>, <a href="#rfc.xref.GET.3">4.1</a>, <a href="#rfc.iref.g.16"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.4">8.1.3</a>, <a href="#rfc.xref.GET.5">B</a></li>
    45114511                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    45124512                     <ul>
    … …  
    46274627                     </ul>
    46284628                  </li>
    4629                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.3.1</a>, <a href="#rfc.xref.Part4.2">5.2</a>, <a href="#rfc.xref.Part4.3">5.2</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">6.1</a>, <a href="#rfc.xref.Part4.8">6.1</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">7.2</a>, <a href="#rfc.xref.Part4.11">7.2</a>, <a href="#rfc.xref.Part4.12">7.2</a>, <a href="#rfc.xref.Part4.13">8.1.2</a>, <a href="#Part4"><b>11.1</b></a><ul>
    4630                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.12">7.2</a></li>
    4631                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.11">7.2</a></li>
    4632                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">5.2</a></li>
    4633                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">5.2</a></li>
    4634                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">5.2</a></li>
    4635                         <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.6">5.2</a></li>
    4636                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.7">6.1</a></li>
    4637                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.8">6.1</a></li>
    4638                         <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.9">6.1</a></li>
     4629                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3</a>, <a href="#rfc.xref.Part4.2">4.3.1</a>, <a href="#rfc.xref.Part4.3">5.2</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">5.2</a>, <a href="#rfc.xref.Part4.8">6.1</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.1</a>, <a href="#rfc.xref.Part4.11">7.2</a>, <a href="#rfc.xref.Part4.12">7.2</a>, <a href="#rfc.xref.Part4.13">7.2</a>, <a href="#rfc.xref.Part4.14">8.1.2</a>, <a href="#Part4"><b>11.1</b></a><ul>
     4630                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.13">7.2</a></li>
     4631                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.12">7.2</a></li>
     4632                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">5.2</a></li>
     4633                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">5.2</a></li>
     4634                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.6">5.2</a></li>
     4635                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.7">5.2</a></li>
     4636                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.8">6.1</a></li>
     4637                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.9">6.1</a></li>
     4638                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.10">6.1</a></li>
    46394639                     </ul>
    46404640                  </li>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2111 r2112  
    307307</t>
    308308<t>
    309    We use the term "<x:dfn>selected representation</x:dfn>" to refer to the
    310    representation of the <x:ref>target resource</x:ref> in a
    311    <x:ref>200 (OK)</x:ref> response to <x:ref>GET</x:ref>, or the
    312    representation that would have been selected in a successful response if
    313    the request had used the method <x:ref>GET</x:ref> and excluded any
    314    conditional request header fields.
     309   An origin server might be provided with, or capable of generating, multiple
     310   representations that are each intended to reflect the current state of a
     311   <x:ref>target resource</x:ref>. In such cases, some algorithm is used by
     312   the origin server to select one of those representations as most applicable
     313   to a given request, usually based on <x:ref>content negotiation</x:ref>.
     314   We refer to that one representation as the
     315   "<x:dfn>selected representation</x:dfn>" and use its particular data and
     316   metadata for evaluating conditional requests <xref target="Part4"/> and
     317   constructing the payload for <x:ref>200 (OK)</x:ref> and
     318   <x:ref>304 (Not Modified)</x:ref> responses to GET (<xref target="GET"/>).
    315319</t>
    316320
    … …  
    727731         (&effective-request-uri;).</t>
    728732      <t>If the request is GET or HEAD and the response status code is
    729          <x:ref>203 (Non-Authoritative Information)</x:ref>, the payload is a
    730          potentially modified representation of the
    731          <x:ref>target resource</x:ref>; as such, the effective request URI
    732          might only act as an identifier for the payload's representation when
    733          a request is made via the same chain of intermediaries.</t>
     733         <x:ref>203 (Non-Authoritative Information)</x:ref>, the payload is
     734         intended to be a representation of the <x:ref>target resource</x:ref>
     735         that has been modified by an intermediary.</t>
    734736      <t>If the response has a <x:ref>Content-Location</x:ref> header field
    735737         and its field-value is a reference to the same URI as the effective
    … …  
    770772   If Content-Location is included in a <x:ref>2xx (Successful)</x:ref>
    771773   response message and its value refers (after conversion to absolute form)
    772    to a URI that is the same as the effective request URI, then the response
    773    payload &SHOULD; be considered a current representation of that resource.
     774   to a URI that is the same as the effective request URI, then
     775   the recipient &MAY; consider the payload to be a current representation of
     776   that resource at the time indicated by the message origination date.
    774777   For a GET or HEAD request, this is the same as the default semantics
    775778   when no Content-Location is provided by the server.  For a state-changing
    … …  
    19791982<t>
    19801983   Conditionals are request header fields that indicate a precondition to be
    1981    tested before applying the method semantics to the <x:ref>target resource</x:ref>.
    1982    Each precondition is based on metadata that is expected to change if the
    1983    selected representation of the target resource is changed.  The HTTP/1.1
    1984    conditional request mechanisms are defined in <xref target="Part4"/>.
     1984   tested before applying the method semantics to the
     1985   <x:ref>target resource</x:ref>. Each precondition is based on metadata that
     1986   is expected to change if the <x:ref>selected representation</x:ref> is
     1987   changed. The HTTP/1.1 conditional request mechanisms are defined in
     1988   <xref target="Part4"/>.
    19851989</t>
    19861990<texttable align="left">
    … …  
    27422746<t>
    27432747   The <x:dfn>200 (OK)</x:dfn> status code indicates that the request has
    2744    succeeded. The meaning of a payload sent in the response depends on the
    2745    request method. For the methods defined by this specification, the payload
    2746    can be summarized as:
     2748   succeeded. The payload sent in a 200 response depends on the request
     2749   method. For the methods defined by this specification, the intended meaning
     2750   of the payload can be summarized as:
    27472751  <list style="hanging">
    27482752    <t hangText="GET">
    … …  
    31173121</t>
    31183122<t>
    3119    A 303 response to a GET request indicates that the
    3120    <x:ref>target resource</x:ref> does not have a representation of
    3121    its own that can be transferred by the server over HTTP.
    3122    The <x:ref>Location</x:ref> field value refers to a resource that is
    3123    descriptive of the target resource, such that the follow-on representation
    3124    might be useful to recipients without implying that it adequately
    3125    represents the target resource. Note that answers to the questions of what
    3126    can be represented, what representations are adequate, and what might be a
    3127    useful description are outside the scope of HTTP.
     3123   A 303 response to a GET request indicates that the origin server does not
     3124   have a representation of the <x:ref>target resource</x:ref> that can be
     3125   transferred by the server over HTTP. However, the
     3126   <x:ref>Location</x:ref> field value refers to a resource that is
     3127   descriptive of the target resource, such that making a retrieval request
     3128   on that other resource might result in a representation that is useful to
     3129   recipients without implying that it represents the original target resource.
     3130   Note that answers to the questions of what can be represented, what
     3131   representations are adequate, and what might be a useful description are
     3132   outside the scope of HTTP.
    31283133</t>
    31293134<t>
Note: See TracChangeset for help on using the changeset viewer.