Ignore:
Timestamp:
Sep 16, 2009, 5:09:34 AM (10 years ago)
Author:
julian.reschke@…
Message:

Clarify rules for determining what entities a response carries (see #110 #196)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r689 r695  
    2222  <!ENTITY caching                    "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2323  <!ENTITY auth                       "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     24  <!ENTITY caching-combining-headers  "<xref target='Part6' x:rel='#combining.headers' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2425  <!ENTITY content-negotiation        "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2526  <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    651652   have been applied to ensure safe and proper transfer of the message.
    652653</t>
     654
     655<section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">
     656<t>
     657   It is sometimes necessary to determine the identity of the resource
     658   associated with a representation.
     659</t>
     660<t>
     661   An HTTP request representation, when present, is always associated with an
     662   anonymous (i.e., unidentified) resource.
     663</t>
     664<t>
     665   In the common case, an HTTP response is a representation of the resource
     666   located at the request-URI. However, this is not always the case. To
     667   determine the URI of the resource a response is associated with, the
     668   following rules are used (first match winning):
     669</t>
     670<t><list style="numbers">
     671   <t>If the response status code is 200 or 203 and the request method was GET,
     672   the response is a representation of the resource at the request-URI.</t>
     673   <t>If the response status is 204, 206, or 304 and the request method was GET
     674   or HEAD, the response is a partial representation of the resource at the
     675   request-URI (see &caching-combining-headers;).</t>
     676   <t>If the response has a Content-Location header, and that URI is the same
     677   as the request-URI <cref>(see [ref])</cref>, the response is a representation of the
     678   resource at the request-URI.</t>
     679   <t>If the response has a Content-Location header, and that URI is not the
     680   same as the request-URI, the response asserts that it is a representation of
     681   the resource at the Content-Location URI (but it may not be).</t>
     682   <t>Otherwise, the response is a representation of an anonymous (i.e.,
     683   unidentified) resource.</t>
     684</list></t>
     685<t>
     686  <cref anchor="TODO-req-uri">
     687   Note that 'request-URI' is used here; however, we need to come up with a
     688   term to denote "the URI that can be inferred from examining the
     689   request-target and the Host header." (see <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196" />).
     690   Also, the comparison function is going to have to be defined somewhere,
     691   because we already need to compare URIs for things like cache invalidation.</cref>
     692</t>
     693</section>
     694
    653695</section>
    654696
     
    36313673    </t>
    36323674    <t>
     3675      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/110"/>:
     3676      "Clarify rules for determining what entities a response carries"
     3677    </t>
     3678    <t>
    36333679      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/140"/>:
    36343680      "update note citing RFC 1945 and 2068"
Note: See TracChangeset for help on using the changeset viewer.