Changeset 695 for draft-ietf-httpbis/latest/p2-semantics.xml

Timestamp:

16/09/09 12:09:34 (13 years ago)

Author:

julian.reschke@…

Message:

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

File:

• draft-ietf-httpbis/latest/p2-semantics.xml (modified) (3 diffs)

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

@@ -22 +22 @@
   <!ENTITY caching                    "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY auth                       "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY caching-combining-headers  "<xref target='Part6' x:rel='#combining.headers' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY content-negotiation        "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -651 +652 @@
    have been applied to ensure safe and proper transfer of the message.
 </t>
+
+<section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">
+<t>
+   It is sometimes necessary to determine the identity of the resource
+   associated with a representation.
+</t>
+<t>
+   An HTTP request representation, when present, is always associated with an
+   anonymous (i.e., unidentified) resource.
+</t>
+<t>
+   In the common case, an HTTP response is a representation of the resource
+   located at the request-URI. However, this is not always the case. To
+   determine the URI of the resource a response is associated with, the
+   following rules are used (first match winning):
+</t>
+<t><list style="numbers">
+   <t>If the response status code is 200 or 203 and the request method was GET,
+   the response is a representation of the resource at the request-URI.</t>
+   <t>If the response status is 204, 206, or 304 and the request method was GET
+   or HEAD, the response is a partial representation of the resource at the
+   request-URI (see &caching-combining-headers;).</t>
+   <t>If the response has a Content-Location header, and that URI is the same
+   as the request-URI <cref>(see [ref])</cref>, the response is a representation of the
+   resource at the request-URI.</t>
+   <t>If the response has a Content-Location header, and that URI is not the
+   same as the request-URI, the response asserts that it is a representation of
+   the resource at the Content-Location URI (but it may not be).</t>
+   <t>Otherwise, the response is a representation of an anonymous (i.e.,
+   unidentified) resource.</t>
+</list></t>
+<t>
+  <cref anchor="TODO-req-uri">
+   Note that 'request-URI' is used here; however, we need to come up with a
+   term to denote "the URI that can be inferred from examining the
+   request-target and the Host header." (see <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196" />).
+   Also, the comparison function is going to have to be defined somewhere,
+   because we already need to compare URIs for things like cache invalidation.</cref>
+</t>
+</section>
+
 </section>
 
@@ -3631 +3673 @@
     </t>
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/110"/>:
+      "Clarify rules for determining what entities a response carries"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/140"/>:
       "update note citing RFC 1945 and 2068"