Ticket #196: i196.6.diff

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

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

  • 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 the 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>
    … …  
    760760<t>
    761761   The OPTIONS method represents a request for information about the
    762762   communication options available on the request/response chain
    763    identified by the request-target. This method allows the client to
     763   identified by the Effective Request URI. This method allows the client to
    764764   determine the options and/or requirements associated with a resource,
    765765   or the capabilities of a server, without implying a resource action
    766766   or initiating a resource retrieval.
    … …  
    825825<t>
    826826   The GET method means retrieve whatever information (in the form of an
    827827   entity) currently corresponds to the resource identified by the
    828    request-target.
     828   Effective Request URI.
    829829</t>
    830830<t>   
    831    If the request-target identifies a data-producing process, it is the
     831   If the Effective Request URI identifies a data-producing process, it is the
    832832   produced data which shall be returned as the entity in the response and not
    833833   the source text of the process, unless that text happens to be the output of
    834834   the process.
    … …  
    893893<t>
    894894   The POST method is used to request that the origin server accept the
    895895   entity enclosed in the request as data to be processed by the resource
    896    identified by the request-target in the Request-Line. POST is designed
     896   identified by the Effective Request URI. POST is designed
    897897   to allow a uniform method to cover the following functions:
    898898  <list style="symbols">
    899899    <t>
    … …  
    914914</t>
    915915<t>
    916916   The actual function performed by the POST method is determined by the
    917    server and is usually dependent on the request-target.
     917   server and is usually dependent on the Effective Request URI.
    918918</t>
    919919<t>
    920920   The action performed by the POST method might not result in a
    … …  
    942942  <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/>
    943943<t>
    944944   The PUT method requests that the enclosed entity be stored at the
    945    supplied request-target. If the request-target refers to an already
     945   Effective Request URI. If the Effective Request URI refers to an already
    946946   existing resource, the enclosed entity &SHOULD; be considered as a
    947    modified version of the one residing on the origin server. If the
    948    request-target does not point to an existing resource, and that URI is
     947   modified version of the one residing on the origin server. Otherwise, if the
     948   Effective Request URI does not point to an existing resource, and that URI is
    949949   capable of being defined as a new resource by the requesting user
    950    agent, the origin server can create the resource with that URI. If a
    951    new resource is created at the request-target, the origin server &MUST;
    952    inform the user agent
     950   agent, the origin server can create the resource with that URI.
     951</t>
     952<t>   
     953   If a new resource is created at the Effective Request URI, the origin
     954   server &MUST; inform the user agent
    953955   via the 201 (Created) response. If an existing resource is modified,
    954956   either the 200 (OK) or 204 (No Content) response codes &SHOULD; be sent
    955    to indicate successful completion of the request. If the resource
    956    could not be created or modified with the request-target, an appropriate
    957    error response &SHOULD; be given that reflects the nature of the
    958    problem. The recipient of the entity &MUST-NOT; ignore any Content-*
     957   to indicate successful completion of the request.
     958</t>
     959<t>   
     960   If the resource could not be created or modified with the Effective Request
     961   URI, an appropriate error response &SHOULD; be given that reflects the nature
     962   of the problem. The recipient of the entity &MUST-NOT; ignore any Content-*
    959963   headers (headers starting with the prefix "Content-") that it does
    960964   not understand or implement
    961965   and &MUST; return a 501 (Not Implemented) response in such cases.
    962966</t>
    963967<t>
    964    If the request passes through a cache and the request-target identifies
    965    one or more currently cached entities, those entries &SHOULD; be
     968   If the request passes through a cache and the Effective Request URI
     969   identifies one or more currently cached entities, those entries &SHOULD; be
    966970   treated as stale. Responses to this method are not cacheable.
    967971</t>
    968972<t>
    969973   The fundamental difference between the POST and PUT requests is
    970    reflected in the different meaning of the request-target. The URI in a
     974   reflected in the different meaning of the Effective Request URI. The URI in a
    971975   POST request identifies the resource that will handle the enclosed
    972976   entity. That resource might be a data-accepting process, a gateway to
    973977   some other protocol, or a separate entity that accepts annotations.
    … …  
    10021006  <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/>
    10031007<t>
    10041008   The DELETE method requests that the origin server delete the resource
    1005    identified by the request-target. This method &MAY; be overridden by human
    1006    intervention (or other means) on the origin server. The client cannot
     1009   identified by the Effective Request URI. This method &MAY; be overridden by
     1010   human intervention (or other means) on the origin server. The client cannot
    10071011   be guaranteed that the operation has been carried out, even if the
    10081012   status code returned from the origin server indicates that the action
    10091013   has been completed successfully. However, the server &SHOULD-NOT;
    … …  
    10181022   but the response does not include an entity.
    10191023</t>
    10201024<t>
    1021    If the request passes through a cache and the request-target identifies
    1022    one or more currently cached entities, those entries &SHOULD; be
     1025   If the request passes through a cache and the Effective Request URI
     1026   identifies one or more currently cached entities, those entries &SHOULD; be
    10231027   treated as stale. Responses to this method are not cacheable.
    10241028</t>
    10251029</section>
    … …  
    13301334   The requested resource has been assigned a new permanent URI and any
    13311335   future references to this resource &SHOULD; use one of the returned
    13321336   URIs.  Clients with link editing capabilities ought to automatically
    1333    re-link references to the request-target to one or more of the new
     1337   re-link references to the Effective Request URI to one or more of the new
    13341338   references returned by the server, where possible. This response is
    13351339   cacheable unless indicated otherwise.
    13361340</t>
    … …  
    13631367<t>
    13641368   The requested resource resides temporarily under a different URI.
    13651369   Since the redirection might be altered on occasion, the client &SHOULD;
    1366    continue to use the request-target for future requests.  This response
     1370   continue to use the Effectice Request URI for future requests.  This response
    13671371   is only cacheable if indicated by a Cache-Control or Expires header
    13681372   field.
    13691373</t>
    … …  
    14761480<t>
    14771481   The requested resource resides temporarily under a different URI.
    14781482   Since the redirection &MAY; be altered on occasion, the client &SHOULD;
    1479    continue to use the request-target for future requests.  This response
     1483   continue to use the Effective Request URI for future requests.  This response
    14801484   is only cacheable if indicated by a Cache-Control or Expires header
    14811485   field.
    14821486</t>
    … …  
    15661570  <iref primary="true" item="404 Not Found (status code)" x:for-anchor=""/>
    15671571  <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/>
    15681572<t>
    1569    The server has not found anything matching the request-target. No
     1573   The server has not found anything matching the Effective Request URI. No
    15701574   indication is given of whether the condition is temporary or
    15711575   permanent. The 410 (Gone) status code &SHOULD; be used if the server
    15721576   knows, through some internally configurable mechanism, that an old
    … …  
    15821586  <iref primary="true" item="Status Codes" subitem="405 Method Not Allowed" x:for-anchor=""/>
    15831587<t>
    15841588   The method specified in the Request-Line is not allowed for the
    1585    resource identified by the request-target. The response &MUST; include an
     1589   resource identified by the Effective Request URI. The response &MUST; include an
    15861590   Allow header containing a list of valid methods for the requested
    15871591   resource.
    15881592</t>
    … …  
    16731677   The requested resource is no longer available at the server and no
    16741678   forwarding address is known. This condition is expected to be
    16751679   considered permanent. Clients with link editing capabilities &SHOULD;
    1676    delete references to the request-target after user approval. If the
     1680   delete references to the Effective Request URI after user approval. If the
    16771681   server does not know, or has no facility to determine, whether or not
    16781682   the condition is permanent, the status code 404 (Not Found) &SHOULD; be
    16791683   used instead. This response is cacheable unless indicated otherwise.
    … …  
    17351739  <iref primary="true" item="414 URI Too Long (status code)" x:for-anchor=""/>
    17361740  <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/>
    17371741<t>
    1738    The server is refusing to service the request because the request-target
     1742   The server is refusing to service the request because the Effective Request URI
    17391743   is longer than the server is willing to interpret. This rare
    17401744   condition is only likely to occur when a client has improperly
    17411745   converted a POST request to a GET request with long query
    … …  
    17431747   redirection (e.g., a redirected URI prefix that points to a suffix of
    17441748   itself), or when the server is under attack by a client attempting to
    17451749   exploit security holes present in some servers using fixed-length
    1746    buffers for reading or manipulating the request-target.
     1750   buffers for reading or manipulating the Effective Request URI.
    17471751</t>
    17481752</section>
    17491753
    … …  
    18951899  <x:anchor-alias value="Allow-v"/>
    18961900<t>
    18971901   The "Allow" response-header field lists the set of methods advertised as
    1898    supported by the resource identified by the request-target. The purpose of
     1902   supported by the resource identified by the Effective Request URI. The purpose of
    18991903   this field is strictly to inform the recipient of valid methods
    19001904   associated with the resource.
    19011905</t>
    … …  
    21282132  <x:anchor-alias value="Referer-v"/>
    21292133<t>
    21302134   The "Referer" [sic] request-header field allows the client to specify the
    2131    URI of the resource from which the request-target was obtained (the
     2135   URI of the resource from which the Effective Request URI was obtained (the
    21322136   "referrer", although the header field is misspelled.).
    21332137</t>
    21342138<t>
    … …  
    21402144   required to contain a Referer header field.
    21412145</t>
    21422146<t>
    2143    If the request-target was obtained from a source that does not have its own
     2147   If the Effective Request URI was obtained from a source that does not have its own
    21442148   URI (e.g., input from the user keyboard), the Referer field &MUST; either be
    21452149   sent with the value "about:blank", or not be sent at all. Note that this
    21462150   requirement does not apply to sources with non-HTTP URIs (e.g., FTP).
    … …  
    21572161</artwork></figure>
    21582162<t>
    21592163   If the field value is a relative URI, it &SHOULD; be interpreted
    2160    relative to the request-target. The URI &MUST-NOT; include a fragment. See
     2164   relative to the Effective Request URI. The URI &MUST-NOT; include a fragment. See
    21612165   <xref target="encoding.sensitive.information.in.uris"/> for security considerations.
    21622166</t>
    21632167</section>

  • p6-cache.xml

     
    1717  <!ENTITY notation                    "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1818  <!ENTITY basic-rules                 "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1919  <!ENTITY uri                         "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     20  <!ENTITY effective-request-uri      "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2021  <!ENTITY messaging                   "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2122  <!ENTITY conditional                 "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2223  <!ENTITY partial                     "<xref target='Part5' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    477478<t>
    478479  For a presented request, a cache &MUST-NOT; return a stored response, unless:
    479480  <list style="symbols">
    480     <t>The presented Request-URI and that of the stored response match
    481       (<cref anchor="TODO-Request-URI">Need to find a new term for this, as Part
    482       1 doesn't define Request-URI anymore; the new term request-target does not
    483       work for this. (see <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196" />)</cref>), and</t>
     481    <t>The presented Effective Request URI (&effective-request-uri;) and that of the stored response match, and</t>
    484482    <t>the request method associated with the stored response allows it to be
    485483      used for the presented request, and</t>
    486484    <t>selecting request-headers nominated by the stored response (if any) match those presented (see <xref
    … …  
    797795  up-to-date.
    798796</t>
    799797<t>
    800   The following HTTP methods &MUST; cause a cache to invalidate the Request-URI as well
     798  The following HTTP methods &MUST; cause a cache to invalidate the Effective Request URI (&effective-request-uri;) as well
    801799  as the URI(s) in the Location and Content-Location headers (if present):
    802800  <list style="symbols">
    803801    <t>PUT</t>
    … …  
    807805</t>
    808806<t>
    809807  An invalidation based on a URI from a Location or Content-Location header &MUST-NOT;
    810   be performed if the host part of that URI differs from the host part in the Request-URI.
     808  be performed if the host part of that URI differs from the host part in the Effective Request URI (&effective-request-uri;).
    811809  This helps prevent denial of service attacks.
    812810</t>
    813811<t>
    … …  
    815813</t>
    816814<t>
    817815  A cache that passes through requests for methods it does not understand &SHOULD;
    818   invalidate the Request-URI.
     816  invalidate the Effective Request URI (&effective-request-uri;).
    819817</t>
    820818<t>
    821819  Here, "invalidate" means that the cache will either remove all stored responses related
    822   to the Request-URI, or will mark these as "invalid" and in need of a mandatory validation
     820  to the Effective Request URI, or will mark these as "invalid" and in need of a mandatory validation
    823821  before they can be returned in response to a subsequent request.
    824822</t>
    825823<t>