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

Ticket #196: i196.7.diff

File i196.7.diff, 28.0 KB (added by julian.reschke@gmx.de, 4 years ago)

Proposed def of "effective request URI", including questions, plus patches for the other parts.

  • 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'/>"> 
     
    422423  <x:anchor-alias value="Method"/> 
    423424  <x:anchor-alias value="extension-method"/> 
    424425<t> 
    425    The Method  token indicates the method to be performed on the 
    426    resource identified by the request-target. The method is case-sensitive. 
     426   The Method token indicates the method to be performed on the resource 
     427   identified by the Effective Request URI (&effective-request-uri;). The 
     428   method is case-sensitive. 
    427429</t> 
    428430<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/> 
    429431  <x:ref>Method</x:ref>         = <x:abnf-char-sequence>"OPTIONS"</x:abnf-char-sequence>   ; "OPTIONS", <xref target="OPTIONS"/> 
     
    620622   The response-header fields allow the server to pass additional 
    621623   information about the response which cannot be placed in the Status-Line. 
    622624   These header fields give information about the server and about 
    623    further access to the resource identified by the request-target. 
     625   further access to the resource identified by the Effective Request URI 
     626   (&effective-request-uri;). 
    624627</t> 
    625628<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="response-header"/> 
    626629  <x:ref>response-header</x:ref> = <x:ref>Accept-Ranges</x:ref>           ; &header-accept-ranges; 
     
    670673</t> 
    671674<t> 
    672675   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): 
     676   located at the Effective Request URI (see &effective-request-uri;). However, 
     677   this is not always the case. To determine the URI of the resource a 
     678   response is associated with, the following rules are used (with the first 
     679   applicable one being selected): 
    676680</t> 
    677681<t><list style="numbers"> 
    678682   <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> 
     683   the response is a representation of the resource at the Effective Request URI.</t> 
    680684   <t>If the response status is 204, 206, or 304 and the request method was GET 
    681685   or HEAD, the response is a partial representation of the resource at the 
    682    request-URI (see &caching-combining-headers;).</t> 
     686   Effective Request URI (see &caching-combining-headers;).</t> 
    683687   <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> 
     688   as the Effective Request URI, the response is a representation of the 
     689   resource at the Effective Request URI.</t> 
    686690   <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> 
     691   same as the Effective Request URI, the response asserts that it is a 
     692   representation of the resource at the Content-Location URI (but it may not 
     693   be).</t> 
    689694   <t>Otherwise, the response is a representation of an anonymous (i.e., 
    690695   unidentified) resource.</t> 
    691696</list></t> 
    692697<t> 
    693698  <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, 
     699   The comparison function is going to have to be defined somewhere, 
    698700   because we already need to compare URIs for things like cache invalidation.</cref> 
    699701</t> 
    700702</section> 
     
    760762<t> 
    761763   The OPTIONS method represents a request for information about the 
    762764   communication options available on the request/response chain 
    763    identified by the request-target. This method allows the client to 
     765   identified by the Effective Request URI. This method allows the client to 
    764766   determine the options and/or requirements associated with a resource, 
    765767   or the capabilities of a server, without implying a resource action 
    766768   or initiating a resource retrieval. 
     
    825827<t> 
    826828   The GET method means retrieve whatever information (in the form of an 
    827829   entity) currently corresponds to the resource identified by the 
    828    request-target. 
     830   Effective Request URI. 
    829831</t> 
    830832<t>    
    831    If the request-target identifies a data-producing process, it is the 
     833   If the Effective Request URI identifies a data-producing process, it is the 
    832834   produced data which shall be returned as the entity in the response and not 
    833835   the source text of the process, unless that text happens to be the output of 
    834836   the process. 
     
    893895<t> 
    894896   The POST method is used to request that the origin server accept the 
    895897   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 
     898   identified by the Effective Request URI. POST is designed 
    897899   to allow a uniform method to cover the following functions: 
    898900  <list style="symbols"> 
    899901    <t> 
     
    914916</t> 
    915917<t> 
    916918   The actual function performed by the POST method is determined by the 
    917    server and is usually dependent on the request-target. 
     919   server and is usually dependent on the Effective Request URI. 
    918920</t> 
    919921<t> 
    920922   The action performed by the POST method might not result in a 
     
    942944  <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/> 
    943945<t> 
    944946   The PUT method requests that the enclosed entity be stored at the 
    945    supplied request-target. If the request-target refers to an already 
     947   Effective Request URI. If the Effective Request URI refers to an already 
    946948   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 
     949   modified version of the one residing on the origin server. Otherwise, if the 
     950   Effective Request URI does not point to an existing resource, and that URI is 
    949951   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 
     952   agent, the origin server can create the resource with that URI. 
     953</t> 
     954<t>    
     955   If a new resource is created at the Effective Request URI, the origin 
     956   server &MUST; inform the user agent 
    953957   via the 201 (Created) response. If an existing resource is modified, 
    954958   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-* 
     959   to indicate successful completion of the request. 
     960</t> 
     961<t>    
     962   If the resource could not be created or modified with the Effective Request  
     963   URI, an appropriate error response &SHOULD; be given that reflects the nature 
     964   of the problem. The recipient of the entity &MUST-NOT; ignore any Content-* 
    959965   headers (headers starting with the prefix "Content-") that it does 
    960966   not understand or implement 
    961967   and &MUST; return a 501 (Not Implemented) response in such cases. 
    962968</t> 
    963969<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 
     970   If the request passes through a cache and the Effective Request URI 
     971   identifies one or more currently cached entities, those entries &SHOULD; be 
    966972   treated as stale. Responses to this method are not cacheable. 
    967973</t> 
    968974<t> 
    969975   The fundamental difference between the POST and PUT requests is 
    970    reflected in the different meaning of the request-target. The URI in a 
     976   reflected in the different meaning of the Effective Request URI. The URI in a 
    971977   POST request identifies the resource that will handle the enclosed 
    972978   entity. That resource might be a data-accepting process, a gateway to 
    973979   some other protocol, or a separate entity that accepts annotations. 
     
    10021008  <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/> 
    10031009<t> 
    10041010   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 
     1011   identified by the Effective Request URI. This method &MAY; be overridden by 
     1012   human intervention (or other means) on the origin server. The client cannot 
    10071013   be guaranteed that the operation has been carried out, even if the 
    10081014   status code returned from the origin server indicates that the action 
    10091015   has been completed successfully. However, the server &SHOULD-NOT;  
     
    10181024   but the response does not include an entity. 
    10191025</t> 
    10201026<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 
     1027   If the request passes through a cache and the Effective Request URI 
     1028   identifies one or more currently cached entities, those entries &SHOULD; be 
    10231029   treated as stale. Responses to this method are not cacheable. 
    10241030</t> 
    10251031</section> 
     
    13301336   The requested resource has been assigned a new permanent URI and any 
    13311337   future references to this resource &SHOULD; use one of the returned 
    13321338   URIs.  Clients with link editing capabilities ought to automatically 
    1333    re-link references to the request-target to one or more of the new 
     1339   re-link references to the Effective Request URI to one or more of the new 
    13341340   references returned by the server, where possible. This response is 
    13351341   cacheable unless indicated otherwise. 
    13361342</t> 
     
    13631369<t> 
    13641370   The requested resource resides temporarily under a different URI. 
    13651371   Since the redirection might be altered on occasion, the client &SHOULD; 
    1366    continue to use the request-target for future requests.  This response 
     1372   continue to use the Effectice Request URI for future requests.  This response 
    13671373   is only cacheable if indicated by a Cache-Control or Expires header 
    13681374   field. 
    13691375</t> 
     
    14761482<t> 
    14771483   The requested resource resides temporarily under a different URI. 
    14781484   Since the redirection &MAY; be altered on occasion, the client &SHOULD; 
    1479    continue to use the request-target for future requests.  This response 
     1485   continue to use the Effective Request URI for future requests.  This response 
    14801486   is only cacheable if indicated by a Cache-Control or Expires header 
    14811487   field. 
    14821488</t> 
     
    15661572  <iref primary="true" item="404 Not Found (status code)" x:for-anchor=""/> 
    15671573  <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/> 
    15681574<t> 
    1569    The server has not found anything matching the request-target. No 
     1575   The server has not found anything matching the Effective Request URI. No 
    15701576   indication is given of whether the condition is temporary or 
    15711577   permanent. The 410 (Gone) status code &SHOULD; be used if the server 
    15721578   knows, through some internally configurable mechanism, that an old 
     
    15821588  <iref primary="true" item="Status Codes" subitem="405 Method Not Allowed" x:for-anchor=""/> 
    15831589<t> 
    15841590   The method specified in the Request-Line is not allowed for the 
    1585    resource identified by the request-target. The response &MUST; include an 
     1591   resource identified by the Effective Request URI. The response &MUST; include an 
    15861592   Allow header containing a list of valid methods for the requested 
    15871593   resource. 
    15881594</t> 
     
    16731679   The requested resource is no longer available at the server and no 
    16741680   forwarding address is known. This condition is expected to be 
    16751681   considered permanent. Clients with link editing capabilities &SHOULD; 
    1676    delete references to the request-target after user approval. If the 
     1682   delete references to the Effective Request URI after user approval. If the 
    16771683   server does not know, or has no facility to determine, whether or not 
    16781684   the condition is permanent, the status code 404 (Not Found) &SHOULD; be 
    16791685   used instead. This response is cacheable unless indicated otherwise. 
     
    17351741  <iref primary="true" item="414 URI Too Long (status code)" x:for-anchor=""/> 
    17361742  <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/> 
    17371743<t> 
    1738    The server is refusing to service the request because the request-target 
     1744   The server is refusing to service the request because the Effective Request URI 
    17391745   is longer than the server is willing to interpret. This rare 
    17401746   condition is only likely to occur when a client has improperly 
    17411747   converted a POST request to a GET request with long query 
     
    17431749   redirection (e.g., a redirected URI prefix that points to a suffix of 
    17441750   itself), or when the server is under attack by a client attempting to 
    17451751   exploit security holes present in some servers using fixed-length 
    1746    buffers for reading or manipulating the request-target. 
     1752   buffers for reading or manipulating the Effective Request URI. 
    17471753</t> 
    17481754</section> 
    17491755 
     
    18951901  <x:anchor-alias value="Allow-v"/> 
    18961902<t> 
    18971903   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 
     1904   supported by the resource identified by the Effective Request URI. The purpose of 
    18991905   this field is strictly to inform the recipient of valid methods 
    19001906   associated with the resource. 
    19011907</t> 
     
    21282134  <x:anchor-alias value="Referer-v"/> 
    21292135<t> 
    21302136   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 
     2137   URI of the resource from which the Effective Request URI was obtained (the 
    21322138   "referrer", although the header field is misspelled.). 
    21332139</t> 
    21342140<t> 
     
    21402146   required to contain a Referer header field. 
    21412147</t> 
    21422148<t> 
    2143    If the request-target was obtained from a source that does not have its own 
     2149   If the Effective Request URI was obtained from a source that does not have its own 
    21442150   URI (e.g., input from the user keyboard), the Referer field &MUST; either be 
    21452151   sent with the value "about:blank", or not be sent at all. Note that this 
    21462152   requirement does not apply to sources with non-HTTP URIs (e.g., FTP). 
     
    21572163</artwork></figure> 
    21582164<t> 
    21592165   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 
     2166   relative to the Effective Request URI. The URI &MUST-NOT; include a fragment. See 
    21612167   <xref target="encoding.sensitive.information.in.uris"/> for security considerations. 
    21622168</t> 
    21632169</section> 
     
    27012707   protocol. 
    27022708</t> 
    27032709<t> 
    2704    Authors of services should not use 
    2705    GET-based forms for the submission of sensitive data because that 
    2706    data will be encoded in the Request-target. Many existing 
    2707    servers, proxies, and user agents log or display the Request-target in 
    2708    places where it might be visible to third parties. Such services can 
     2710   Authors of services should not use GET-based forms for the submission of 
     2711   sensitive data because that data will be encoded in the request-target. Many 
     2712   existing servers, proxies, and user agents log or display the request-target 
     2713   in places where it might be visible to third parties. Such services can 
    27092714   use POST-based form submission instead. 
    27102715</t> 
    27112716</section> 
  • p3-payload.xml

     
    3232  <!ENTITY full-date                "<xref target='Part1' x:rel='#date.time.formats.full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    3333  <!ENTITY qvalue                   "<xref target='Part1' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    3434  <!ENTITY uri                      "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
     35  <!ENTITY effective-request-uri    "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    3536  <!ENTITY compression-codings      "<xref target='Part1' x:rel='#compression.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    3637  <!ENTITY transfer-codings         "<xref target='Part1' x:rel='#transfer.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    3738  <!ENTITY compress-coding          "<xref target='Part1' x:rel='#compress.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
     
    13371338</artwork></figure> 
    13381339<t> 
    13391340   The content-coding is a characteristic of the entity identified by 
    1340    the request-target. Typically, the entity-body is stored with this 
     1341   the Effective Request URI (&effective-request-uri;). Typically, the entity-body is stored with this 
    13411342   encoding and is only decoded before rendering or analogous usage. 
    13421343   However, a non-transparent proxy &MAY; modify the content-coding if the 
    13431344   new coding is known to be acceptable to the recipient, unless the 
     
    14381439                    <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref> 
    14391440</artwork></figure> 
    14401441<t> 
    1441    The Content-Location value is not a replacement for the original 
    1442    requested URI; it is only a statement of the location of the resource 
     1442   The Content-Location value is not a replacement for the Effective 
     1443   Request URI (&effective-request-uri;); it is only a statement of the location of the resource 
    14431444   corresponding to this particular entity at the time of the request. 
    1444    Future requests &MAY; specify the Content-Location URI as the request-target 
     1445   Future requests &MAY; may be addressed to the Content-Location URI 
    14451446   if the desire is to identify the source of that particular 
    14461447   entity. 
    14471448</t> 
     
    14571458</t> 
    14581459<t> 
    14591460   If the Content-Location is a relative URI, the relative URI is 
    1460    interpreted relative to the request-target. 
     1461   interpreted relative to the Effective Request URI. 
    14611462</t> 
    14621463<t> 
    14631464   The meaning of the Content-Location header in requests is 
  • 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> 
  • p7-auth.xml

     
    1717  <!ENTITY notation                     "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    1818  <!ENTITY notation-abnf                "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    1919  <!ENTITY basic-rules                  "<xref target='Part1' x:rel='#basic.rules' 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 shared-and-non-shared-caches "<xref target='Part6' x:rel='#shared.and.non-shared.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    2122]> 
    2223<?rfc toc="yes" ?> 
     
    400401<t> 
    401402   The "Proxy-Authenticate" response-header field consists of a challenge that 
    402403   indicates the authentication scheme and parameters applicable to the proxy 
    403    for this request-target. It &MUST; be included as part 
     404   for this Effective Request URI (&effective-request-uri;). It &MUST; be included as part 
    404405   of a 407 (Proxy Authentication Required) response. 
    405406</t> 
    406407<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/><iref primary="true" item="Grammar" subitem="Proxy-Authenticate-v"/> 
     
    459460<t> 
    460461   The "WWW-Authenticate" response-header field consists of at least one 
    461462   challenge that indicates the authentication scheme(s) and parameters 
    462    applicable to the request-target. It &MUST; be included in 401 
     463   applicable to the Effective Request URI (&effective-request-uri;). It &MUST; be included in 401 
    463464   (Unauthorized) response messages. 
    464465</t> 
    465466<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/><iref primary="true" item="Grammar" subitem="WWW-Authenticate-v"/>