Ticket #196: i196.diff

File i196.diff, 6.3 KB (added by julian.reschke@…, 9 years ago)

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

  • p1-messaging.xml

     
    15861586</t>
    15871587</section>
    15881588
     1589<section title="Effective Request URI" anchor="effective.request.uri">
     1590  <iref primary="true" item="Effective Request URI"/>
     1591<t>
     1592   The term "Effective Request URI" is introduced in order to abstract away
     1593   the various syntactical forms a request can take.
     1594</t>
     1595<t>
     1596   If the request-target is an absolute-URI, then the Effective Request URI is
     1597   the request-target. <cref anchor="effrequri-scheme" source="jre">What
     1598   about the case where the given scheme name and the transport disagree? What if
     1599   actual and specified port disagree?</cref>
     1600</t>
     1601<t>
     1602   If the request-target uses the path-absolute (plus optional query) syntax,
     1603   then the Effective Request URI is constructed by concatenating
     1604</t>
     1605<t>
     1606  <list style="symbols">
     1607    <t>
     1608      the scheme name: "http" if the request was received over an insecure
     1609      TCP connection, or "https" when received over SSL/TLS-secured TCP
     1610      connection, <cref anchor="effrequri-othertransports" source="jre">Need to
     1611      mention other future transports here?</cref>
     1612    </t>
     1613    <t>
     1614      the character sequence "://",
     1615    </t>
     1616    <t>
     1617      the authority component, as specified in the Host header
     1618      (<xref target="header.host"/>) and determined by the rules in
     1619      <xref target="the.resource.identified.by.a.request"/>,
     1620      <cref anchor="effrequri-nohost" source="jre">How do we deal with undefined hosts?</cref>
     1621      and
     1622    </t>
     1623    <t>
     1624      the request-target obtained from the Request-Line.
     1625    </t>
     1626  </list>
     1627</t>
     1628<t>
     1629   Otherwise, when request-target is an asterisk ("*") or uses the authority
     1630   form, the Effective Request URI is undefined.
     1631</t>
     1632<figure>
     1633<preamble>
     1634   Example: the Effective Request URI for the message
     1635</preamble>
     1636<artwork type="example" x:indent-with="  ">
     1637GET /pub/WWW/TheProject.html HTTP/1.1
     1638Host: www.example.org:8080
     1639</artwork>
     1640<postamble>
     1641  (received over an insecure TCP connection) is "http", plus "://", plus the
     1642  authority component "www.example.org:8080", plus the request-target
     1643  "/pub/WWW/TheProject.html", thus
     1644  "http://www.example.org:8080/pub/WWW/TheProject.html".
     1645</postamble>
     1646</figure>
     1647<t>
     1648<cref anchor="effrequri-compare" source="jre">Need to declare comparison?
     1649Can we re-use the comparison defined in <xref target="uri.comparison"/>?</cref>
     1650</t> 
    15891651</section>
    15901652
     1653</section>
    15911654
     1655
    15921656<section title="Response" anchor="response">
    15931657  <x:anchor-alias value="Response"/>
    15941658<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>