Ticket #196: i196.diff

p1-messaging.xml

@@ -1586 +1586 @@
 </t>
 </section>
 
+<section title="Effective Request URI" anchor="effective.request.uri">
+  <iref primary="true" item="Effective Request URI"/>
+<t>
+   The term "Effective Request URI" is introduced in order to abstract away
+   the various syntactical forms a request can take.
+</t>
+<t>
+   If the request-target is an absolute-URI, then the Effective Request URI is
+   the request-target. <cref anchor="effrequri-scheme" source="jre">What 
+   about the case where the given scheme name and the transport disagree? What if
+   actual and specified port disagree?</cref>
+</t>
+<t>
+   If the request-target uses the path-absolute (plus optional query) syntax,
+   then the Effective Request URI is constructed by concatenating
+</t>
+<t>
+  <list style="symbols">
+    <t>
+      the scheme name: "http" if the request was received over an insecure
+      TCP connection, or "https" when received over SSL/TLS-secured TCP
+      connection, <cref anchor="effrequri-othertransports" source="jre">Need to
+      mention other future transports here?</cref>
+    </t>
+    <t>
+      the character sequence "://",
+    </t>
+    <t>
+      the authority component, as specified in the Host header
+      (<xref target="header.host"/>) and determined by the rules in
+      <xref target="the.resource.identified.by.a.request"/>,
+      <cref anchor="effrequri-nohost" source="jre">How do we deal with undefined hosts?</cref>
+      and
+    </t>
+    <t>
+      the request-target obtained from the Request-Line.
+    </t>
+  </list>
+</t>
+<t>
+   Otherwise, when request-target is an asterisk ("*") or uses the authority
+   form, the Effective Request URI is undefined.
+</t>
+<figure>
+<preamble>
+   Example: the Effective Request URI for the message
+</preamble> 
+<artwork type="example" x:indent-with="  ">
+GET /pub/WWW/TheProject.html HTTP/1.1
+Host: www.example.org:8080
+</artwork>
+<postamble>
+  (received over an insecure TCP connection) is "http", plus "://", plus the
+  authority component "www.example.org:8080", plus the request-target
+  "/pub/WWW/TheProject.html", thus
+  "http://www.example.org:8080/pub/WWW/TheProject.html".
+</postamble>
+</figure>
+<t>
+<cref anchor="effrequri-compare" source="jre">Need to declare comparison?
+Can we re-use the comparison defined in <xref target="uri.comparison"/>?</cref>
+</t>  
 </section>
 
+</section>
 
+
 <section title="Response" anchor="response">
   <x:anchor-alias value="Response"/>
 <t>

p2-semantics.xml

@@ -26 +26 @@
   <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY basic-rules                "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY uri                        "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY effective-request-uri      "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY full-date                  "<xref target='Part1' x:rel='#date.time.formats.full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY http-url                   "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY http-version               "<xref target='Part1' x:rel='#http.version' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -670 +671 @@
 </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 (with the first applicable one being selected):
+   located at the Effective Request URI (see &effective-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 (with the first
+   applicable one being selected):
 </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>
+   the response is a representation of the resource at the Effective 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>
+   Effective 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 anchor="TODO-missref-requri">(see [ref])</cref>, the response is a representation of the
-   resource at the request-URI.</t>
+   as the Effective Request URI, the response is a representation of the
+   resource at Effective 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>
+   same as the Effective 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,
+   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>