Ignore:
Timestamp:
May 26, 2010, 10:25:13 AM (9 years ago)
Author:
julian.reschke@…
Message:

Introduce term "effective request URI" and use it throughout; may require some more fine-tuning (see #196)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r818 r823  
    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'/>">
     
    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"/>
     
    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"/>
     
    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>
     
    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>
     
    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
     
    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
     
    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">
     
    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>
     
    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
     
    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
     
    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
     
    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>
     
    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.
     
    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.
     
    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.
     
    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
     
    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.
     
    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
     
    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
     
    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>
     
    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.
     
    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>
     
    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
     
    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>
     
    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>
     
    37813786      "Location header payload handling"
    37823787    </t>
     3788    <t>
     3789      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>:
     3790      "Term for the requested resource's URI"
     3791    </t>
    37833792  </list>
    37843793</t>
Note: See TracChangeset for help on using the changeset viewer.