Ticket #196: i196.4.diff

File i196.4.diff, 6.8 KB (added by julian.reschke@…, 13 years ago)

Proposed def of "effective request URI", including questions, plus patches for Part 2

  • p1-messaging.xml

     
    15891589</t>
    15901590</section>
    15911591
     1592<section title="Effective Request URI" anchor="effective.request.uri">
     1593  <iref primary="true" item="Effective Request URI"/>
     1594<t>
     1595   HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>)
     1596   for the resource they are intended for; instead, the value needs to be inferred from the
     1597   request-target, Host header and other context. The result of this process is
     1598   the "Effective Request URI".
     1599</t>
     1600<t>
     1601   If the request-target is an absolute-URI, then the Effective Request URI is
     1602   the request-target.
     1603</t>
     1604<t>
     1605   If the request-target uses the path-absolute (plus optional query) syntax
     1606   or if it is just the asterisk "*", then the Effective Request URI is
     1607   constructed by concatenating
     1608</t>
     1609<t>
     1610  <list style="symbols">
     1611    <t>
     1612      the scheme name: "http" if the request was received over an insecure
     1613      TCP connection, or "https" when received over SSL/TLS-secured TCP
     1614      connection,
     1615    </t>
     1616    <t>
     1617      the character sequence "://",
     1618    </t>
     1619    <t>
     1620      the authority component, as specified in the Host header
     1621      (<xref target="header.host"/>) and determined by the rules in
     1622      <xref target="the.resource.identified.by.a.request"/>,
     1623      <cref anchor="effrequri-nohost" source="jre">Do we need to include the handling of missing hosts in HTTP/1.0 messages, as
     1624      described in <xref target="the.resource.identified.by.a.request"/>?</cref>
     1625      and
     1626    </t>
     1627    <t>
     1628      the request-target obtained from the Request-Line, unless the
     1629      request-target is just the asterisk "*".
     1630    </t>
     1631  </list>
     1632</t>
     1633<t>
     1634   Otherwise, when request-target uses the authority form, the Effective
     1635   Request URI is undefined.
     1636</t>
     1637<figure>
     1638<preamble>
     1639   Example 1: the Effective Request URI for the message
     1640</preamble>
     1641<artwork type="example" x:indent-with="  ">
     1642GET /pub/WWW/TheProject.html HTTP/1.1
     1643Host: www.example.org:8080
     1644</artwork>
     1645<postamble>
     1646  (received over an insecure TCP connection) is "http", plus "://", plus the
     1647  authority component "www.example.org:8080", plus the request-target
     1648  "/pub/WWW/TheProject.html", thus
     1649  "http://www.example.org:8080/pub/WWW/TheProject.html".
     1650</postamble>
     1651</figure>
     1652<figure>
     1653<preamble>
     1654   Example 2: the Effective Request URI for the message
     1655</preamble>
     1656<artwork type="example" x:indent-with="  ">
     1657GET * HTTP/1.1
     1658Host: www.example.org
     1659</artwork>
     1660<postamble>
     1661  (received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the
     1662  authority component "www.example.org", thus "https://www.example.org".
     1663</postamble>
     1664</figure>
     1665<t>
     1666   Effective Request URIs are compared using the rules described in
     1667   <xref target="uri.comparison"/>, except that empty path components &MUST-NOT;
     1668   be treated as equivalent to an absolute path of "/".
     1669</t> 
    15921670</section>
    15931671
     1672</section>
    15941673
     1674
    15951675<section title="Response" anchor="response">
    15961676  <x:anchor-alias value="Response"/>
    15971677<t>

  • p2-semantics.xml

     
    2626  <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2727  <!ENTITY basic-rules                "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2828  <!ENTITY uri                        "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     29  <!ENTITY effective-request-uri      "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2930  <!ENTITY full-date                  "<xref target='Part1' x:rel='#date.time.formats.full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3031  <!ENTITY http-url                   "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3132  <!ENTITY http-version               "<xref target='Part1' x:rel='#http.version' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    670671</t>
    671672<t>
    672673   In the common case, an HTTP response is a representation of the resource
    673    located at the request-URI. However, this is not always the case. To
    674    determine the URI of the resource a response is associated with, the
    675    following rules are used (with the first applicable one being selected):
     674   located at the Effective Request URI (see &effective-request-uri;). However,
     675   this is not always the case. To determine the URI of the resource a
     676   response is associated with, the following rules are used (with the first
     677   applicable one being selected):
    676678</t>
    677679<t><list style="numbers">
    678680   <t>If the response status code is 200 or 203 and the request method was GET,
    679    the response is a representation of the resource at the request-URI.</t>
     681   the response is a representation of the resource at the Effective Request URI.</t>
    680682   <t>If the response status is 204, 206, or 304 and the request method was GET
    681683   or HEAD, the response is a partial representation of the resource at the
    682    request-URI (see &caching-combining-headers;).</t>
     684   Effective Request URI (see &caching-combining-headers;).</t>
    683685   <t>If the response has a Content-Location header, and that URI is the same
    684    as the request-URI <cref anchor="TODO-missref-requri">(see [ref])</cref>, the response is a representation of the
    685    resource at the request-URI.</t>
     686   as the Effective Request URI, the response is a representation of the
     687   resource at Effective Request URI.</t>
    686688   <t>If the response has a Content-Location header, and that URI is not the
    687    same as the request-URI, the response asserts that it is a representation of
    688    the resource at the Content-Location URI (but it may not be).</t>
     689   same as the Effective Request URI, the response asserts that it is a
     690   representation of the resource at the Content-Location URI (but it may not
     691   be).</t>
    689692   <t>Otherwise, the response is a representation of an anonymous (i.e.,
    690693   unidentified) resource.</t>
    691694</list></t>
    692695<t>
    693696  <cref anchor="TODO-req-uri">
    694    Note that "request-URI" is used here; however, we need to come up with a
    695    term to denote "the URI that can be inferred from examining the
    696    request-target and the Host header." (see <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196" />).
    697    Also, the comparison function is going to have to be defined somewhere,
     697   The comparison function is going to have to be defined somewhere,
    698698   because we already need to compare URIs for things like cache invalidation.</cref>
    699699</t>
    700700</section>