* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #196: i196.3.diff

File i196.3.diff, 6.9 KB (added by julian.reschke@gmx.de, 4 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>