Ticket #196: i196.3.diff

File i196.3.diff, 6.9 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   The term "Effective Request URI" is introduced in order to abstract away
     1596   the various syntactical forms a request can take.
     1597</t>
     1598<t>
     1599   If the request-target is an absolute-URI, then the Effective Request URI is
     1600   the request-target. <cref anchor="effrequri-scheme" source="jre">What
     1601   about the case where the given scheme name and the transport disagree? What if
     1602   actual and specified port disagree?</cref>
     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, <cref anchor="effrequri-othertransports" source="jre">Need to
     1615      mention other future transports here?</cref>
     1616    </t>
     1617    <t>
     1618      the character sequence "://",
     1619    </t>
     1620    <t>
     1621      the authority component, as specified in the Host header
     1622      (<xref target="header.host"/>) and determined by the rules in
     1623      <xref target="the.resource.identified.by.a.request"/>,
     1624      <cref anchor="effrequri-nohost" source="jre">How do we deal with undefined hosts?</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<x:note>
     1666  <t>
     1667    <cref anchor="eru-options" source="jre">Need to point out that we are
     1668    not defining an URI for OPTIONS * here.</cref>
     1669  </t>
     1670</x:note>
     1671<t>
     1672<cref anchor="effrequri-compare" source="jre">Need to declare comparison?
     1673Can we re-use the comparison defined in <xref target="uri.comparison"/>?</cref>
     1674</t> 
    15921675</section>
    15931676
     1677</section>
    15941678
     1679
    15951680<section title="Response" anchor="response">
    15961681  <x:anchor-alias value="Response"/>
    15971682<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>