Changeset 1161


Ignore:
Timestamp:
Mar 10, 2011, 9:37:52 PM (8 years ago)
Author:
fielding@…
Message:

editorial consistency:
Use "request method" when talking about HTTP method tokens
unless it is obvious from context.
Make method descriptions a bit more consistent.

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1159 r1161  
    14051405   because the associated response header fields (e.g., Transfer-Encoding,
    14061406   Content-Length, etc.) only indicate what their values would have been
    1407    if the method had been GET.  All 1xx (Informational), 204 (No Content),
     1407   if the request method had been GET.  All 1xx (Informational), 204 (No Content),
    14081408   and 304 (Not Modified) responses &MUST-NOT; include a message-body.
    14091409   All other responses do include a message-body, although the body
     
    16041604  <x:anchor-alias value="Method"/>
    16051605<t>
    1606    The Method  token indicates the method to be performed on the
    1607    resource identified by the request-target. The method is case-sensitive.
     1606   The Method token indicates the request method to be performed on the
     1607   target resource. The request method is case-sensitive.
    16081608</t>
    16091609<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/>
     
    16151615  <x:anchor-alias value="request-target"/>
    16161616<t>
    1617    The request-target identifies the resource upon which to apply the request.
     1617   The request-target identifies the target resource upon which to apply the request.
    16181618</t>
    16191619<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-target"/>
     
    16301630   The asterisk "*" ("asterisk form") means that the request does not apply to a
    16311631   particular resource, but to the server itself. This is only allowed for the
    1632    OPTIONS method. Thus, the only valid example is
     1632   OPTIONS request method. Thus, the only valid example is
    16331633</t>
    16341634<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     
    16551655</t>
    16561656<t><iref item="authority form (of request-target)"/>
    1657    The "authority form" is only used by the CONNECT method (&CONNECT;).
     1657   The "authority form" is only used by the CONNECT request method (&CONNECT;).
    16581658</t>
    16591659<t><iref item="path-absolute form (of request-target)"/>
     
    16771677</t>
    16781678<t>
    1679    If a proxy receives a request without any path in the request-target and
    1680    the method specified is capable of supporting the asterisk form of
    1681    request-target, then the last proxy on the request chain &MUST; forward the
    1682    request with "*" as the final request-target.
     1679   If a proxy receives an OPTIONS request without any path in the
     1680   request-target, then the last proxy on the request chain &MUST;
     1681   forward the request with "*" as the final request-target.
    16831682</t>
    16841683<figure><preamble>   
     
    16881687</artwork></figure>
    16891688<figure><preamble>   
    1690   would be forwarded by the proxy as
     1689  would be forwarded by the final proxy as
    16911690</preamble><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    16921691OPTIONS * HTTP/1.1
     
    25252524</t>
    25262525<t>
    2527    Clients &SHOULD-NOT;  pipeline requests using non-idempotent methods or
    2528    non-idempotent sequences of methods (see &idempotent-methods;). Otherwise, a
     2526   Clients &SHOULD-NOT; pipeline requests using non-idempotent request methods or
     2527   non-idempotent sequences of request methods (see &idempotent-methods;). Otherwise, a
    25292528   premature termination of the transport connection could lead to
    25302529   indeterminate results. A client wishing to send a non-idempotent
     
    26962695   transport connection and retransmit the aborted sequence of requests
    26972696   without user interaction so long as the request sequence is
    2698    idempotent (see &idempotent-methods;). Non-idempotent methods or sequences
     2697   idempotent (see &idempotent-methods;). Non-idempotent request methods or sequences
    26992698   &MUST-NOT; be automatically retried, although user agents &MAY; offer a
    27002699   human operator the choice of retrying the request(s). Confirmation by
     
    28042803        code, it &MAY; close the transport connection or it &MAY; continue
    28052804        to read and discard the rest of the request.  It &MUST-NOT;
    2806         perform the requested method if it returns a final status code.
     2805        perform the request method if it returns a final status code.
    28072806    </t>
    28082807    <t> An origin server &SHOULD-NOT;  send a 100 (Continue) response if
     
    30383037   The "Content-Length" header field indicates the size of the
    30393038   message-body, in decimal number of octets, for any message other than
    3040    a response to the HEAD method or a response with a status code of 304.
    3041    In the case of responses to the HEAD method, it indicates the size of
    3042    the payload body (not including any potential transfer-coding) that
    3043    would have been sent had the request been a GET.
    3044    In the case of the 304 (Not Modified) response, it indicates the size of
    3045    the payload body (not including any potential transfer-coding) that
    3046    would have been sent in a 200 (OK) response.
     3039   a response to a HEAD request or a response with a status code of 304.
     3040   In the case of a response to a HEAD request, Content-Length indicates
     3041   the size of the payload body (not including any potential transfer-coding)
     3042   that would have been sent had the request been a GET.
     3043   In the case of a 304 (Not Modified) response to a GET request,
     3044   Content-Length indicates the size of the payload body (not including
     3045   any potential transfer-coding) that would have been sent in a 200 (OK)
     3046   response.
    30473047</t>
    30483048<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/><iref primary="true" item="Grammar" subitem="Content-Length-v"/>
     
    33843384   supported protocol while indicating to the server that it would like
    33853385   to use a "better" protocol if available (where "better" is determined
    3386    by the server, possibly according to the nature of the method and/or
    3387    resource being requested).
     3386   by the server, possibly according to the nature of the request method
     3387   or target resource).
    33883388</t>
    33893389<t>
     
    48684868   since 1990. The first version of HTTP, later referred to as HTTP/0.9,
    48694869   was a simple protocol for hypertext data transfer across the Internet
    4870    with only a single method and no metadata.
     4870   with only a single request method (GET) and no metadata.
    48714871   HTTP/1.0, as defined by <xref target="RFC1945"/>, added a range of request
    48724872   methods and MIME-like messaging that could include metadata about the data
     
    50235023  Update use of abs_path production from RFC 1808 to the path-absolute + query
    50245024  components of RFC 3986. State that the asterisk form is allowed for the OPTIONS
    5025   method only.
     5025  request method only.
    50265026  (<xref target="request-target"/>)
    50275027</t>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1160 r1161  
    430430  <x:anchor-alias value="extension-method"/>
    431431<t>
    432    The Method token indicates the method to be performed on the target
     432   The Method token indicates the request method to be performed on the target
    433433   resource (&effective-request-uri;). The method is case-sensitive.
    434434</t>
     
    468468</texttable>
    469469<t>
    470   Note that this list is not exhaustive &mdash; it does not include methods defined
     470  Note that this list is not exhaustive &mdash; it does not include request methods defined
    471471  in other specifications.
    472472</t>
     
    811811<section title="Method Definitions" anchor="method.definitions">
    812812<t>
    813    The set of common methods for HTTP/1.1 is defined below. Although
     813   The set of common request methods for HTTP/1.1 is defined below. Although
    814814   this set can be expanded, additional methods cannot be assumed to
    815815   share the same semantics for separately extended clients and servers.
     
    828828<t>
    829829   In particular, the convention has been established that the GET, HEAD,
    830    OPTIONS, and TRACE methods &SHOULD-NOT; have the significance of taking an action
    831    other than retrieval. These methods ought to be considered "<x:dfn anchor="safe">safe</x:dfn>".
     830   OPTIONS, and TRACE request methods &SHOULD-NOT; have the significance
     831   of taking an action other than retrieval. These request methods ought
     832   to be considered "<x:dfn anchor="safe">safe</x:dfn>".
    832833   This allows user agents to represent other methods, such as POST, PUT
    833834   and DELETE, in a special way, so that the user is made aware of the
     
    846847<iref item="Idempotent Methods" primary="true"/>
    847848<t>
    848    Methods can also have the property of "idempotence" in that, aside
    849    from error or expiration issues, the intended effect of multiple
     849   Request methods can also have the property of "idempotence" in that,
     850   aside from error or expiration issues, the intended effect of multiple
    850851   identical requests is the same as for a single request.
    851    The methods PUT, DELETE, and all safe methods are idempotent.
     852   PUT, DELETE, and all safe request methods are idempotent.
    852853   It is important to note that idempotence refers only to changes
    853854   requested by the client: a server is free to change its state due
     
    865866  <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/>
    866867<t>
    867    The OPTIONS method represents a request for information about the
     868   The OPTIONS method requests information about the
    868869   communication options available on the request/response chain
    869    identified by the effective request URI. This method allows the client to
     870   identified by the effective request URI. This method allows a client to
    870871   determine the options and/or requirements associated with a resource,
    871872   or the capabilities of a server, without implying a resource action
     
    873874</t>
    874875<t>
    875    Responses to this method are not cacheable.
     876   Responses to the OPTIONS method are not cacheable.
    876877</t>
    877878<t>
     
    924925  <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/>
    925926<t>
    926    The GET method means retrieve whatever information (in the form of a
    927    representation) currently corresponds to the target resource.
     927   The GET method requests transfer of a current representation of
     928   the target resource.
    928929</t>
    929930<t>   
     
    937938   request message includes an If-Modified-Since, If-Unmodified-Since,
    938939   If-Match, If-None-Match, or If-Range header field. A conditional GET
    939    method requests that the representation be transferred only under the
     940   requests that the representation be transferred only under the
    940941   circumstances described by the conditional header field(s). The
    941    conditional GET method is intended to reduce unnecessary network
     942   conditional GET request is intended to reduce unnecessary network
    942943   usage by allowing cached representations to be refreshed without requiring
    943944   multiple requests or transferring data already held by the client.
     
    947948   request message includes a Range header field. A partial GET requests
    948949   that only part of the representation be transferred, as described in &header-range;.
    949    The partial GET method is intended to reduce unnecessary
     950   The partial GET request is intended to reduce unnecessary
    950951   network usage by allowing partially-retrieved representations to be
    951952   completed without transferring data already held by the client.
     
    991992  <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/>
    992993<t>
    993    The POST method is used to request that the origin server accept the
     994   The POST method requests that the origin server accept the
    994995   representation enclosed in the request as data to be processed by the
    995996   target resource. POST is designed to allow a uniform method to cover the
     
    10471048  <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/>
    10481049<t>
    1049    The PUT method is used to request that the state of the target resource
     1050   The PUT method requests that the state of the target resource
    10501051   be created or replaced with the state defined by the representation
    10511052   enclosed in the request message payload.  A successful PUT of a given
     
    11981199  <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/>
    11991200<t>
    1200    The TRACE method is used to invoke a remote, application-layer loop-back
     1201   The TRACE method requests a remote, application-layer loop-back
    12011202   of the request message. The final recipient of the request
    12021203   &SHOULD; reflect the message received back to the client as the
     
    12271228  <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/>
    12281229<t>
    1229    The CONNECT method is used with a proxy to dynamically switch
    1230    the connection to a tunnel.
    1231 </t>
    1232 <t>
    1233    When using CONNECT, the request-target &MUST; be use the authority form
    1234    (&request-target;); i.e., the host name and port number destination of the
    1235    requested connection separated by a colon:
     1230   The CONNECT method requests that the proxy establish a tunnel
     1231   to the request-target and then restrict its behavior to blind
     1232   forwarding of packets until the connection is closed.
     1233</t>
     1234<t>
     1235   When using CONNECT, the request-target &MUST; use the authority form
     1236   (&request-target;); i.e., the request-target consists of only the
     1237   host name and port number of the tunnel destination, separated by a colon.
     1238   For example,
    12361239</t>
    12371240<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     
    20062009  <iref primary="true" item="Status Codes" subitem="415 Unsupported Media Type" x:for-anchor=""/>
    20072010<t>
    2008    The server is refusing to service the request because the representation of
    2009    the request is in a format not supported by the target resource
    2010    for the requested method.
     2011   The server is refusing to service the request because the request
     2012   payload is in a format not supported by this request method on the
     2013   target resource.
    20112014</t>
    20122015</section>
     
    21702173   The "Allow" response-header field lists the set of methods advertised as
    21712174   supported by the target resource. The purpose of this field is strictly to
    2172    inform the recipient of valid methods associated with the resource.
     2175   inform the recipient of valid request methods associated with the resource.
    21732176</t>
    21742177<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/><iref primary="true" item="Grammar" subitem="Allow-v"/>
     
    23902393</t>
    23912394<t>
    2392    The Max-Forwards header field &MAY; be ignored for all other methods.
     2395   The Max-Forwards header field &MAY; be ignored for all other request
     2396   methods.
    23932397</t>
    23942398</section>
     
    25712575<section title="Method Registry" anchor="method.registration">
    25722576<t>
    2573   The registration procedure for HTTP Methods is defined by
     2577  The registration procedure for HTTP request methods is defined by
    25742578  <xref target="method.registry"/> of this document.
    25752579</t>
     
    29762980</t>
    29772981<t>
    2978    Some methods, like TRACE (<xref target="TRACE"/>), expose information
     2982   Some request methods, like TRACE (<xref target="TRACE"/>), expose information
    29792983   that was sent in request header fields within the body of their response.
    29802984   Clients &SHOULD; be careful with sensitive information, like Cookies,
    2981    Authorization credentials and other header fields that might be used to
     2985   Authorization credentials, and other header fields that might be used to
    29822986   collect data from the client.
    29832987</t>
  • draft-ietf-httpbis/latest/p3-payload.xml

    r1153 r1161  
    14431443   For a GET or HEAD request, this is the same as the default semantics
    14441444   when no Content-Location is provided by the server.  For a state-changing
    1445    method like PUT or POST, it implies that the server's response contains
     1445   request like PUT or POST, it implies that the server's response contains
    14461446   the new representation of that resource, thereby distinguishing it from
    14471447   representations that might only report about the action (e.g., "It worked!").
     
    14601460   contains a report on the action's status and the same report is
    14611461   available (for future access with GET) at the given URI.  For
    1462    example, a purchase transaction made via the POST method might
     1462   example, a purchase transaction made via a POST request might
    14631463   include a receipt document as the payload of the 200 response;
    14641464   the Content-Location value provides an identifier for retrieving
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1145 r1161  
    802802   representation exists, the server &MUST-NOT; perform the requested method, and
    803803   &MUST; return a 412 (Precondition Failed) response. This behavior is
    804    most useful when the client wants to prevent an updating method, such
    805    as PUT, from modifying a resource that has changed since the client
     804   most useful when the client wants to prevent an updating request method,
     805   such as PUT, from modifying a resource that has changed since the client
    806806   last retrieved it.
    807807</t>
     
    812812</t>
    813813<t>
    814    The meaning of "If-Match: *" is that the method &SHOULD; be performed
     814   The meaning of "If-Match: *" is that the request method &SHOULD; be performed
    815815   if the representation selected by the origin server (or by a cache,
    816816   possibly using the Vary mechanism, see &header-vary;) exists, and
     
    937937<t>
    938938   This allows efficient updates of cached information with a minimum amount of
    939    transaction overhead. It is also used to prevent a method (e.g., PUT)
     939   transaction overhead. It is also used to prevent a request method (e.g., PUT)
    940940   from inadvertently modifying an existing resource when the client
    941941   believes that the resource does not exist.
     
    978978</t>
    979979<t>
    980    The meaning of "If-None-Match: *" is that the method &MUST-NOT; be
     980   The meaning of "If-None-Match: *" is that the request method &MUST-NOT; be
    981981   performed if the representation selected by the origin server (or by
    982982   a cache, possibly using the Vary mechanism, see &header-vary;)
Note: See TracChangeset for help on using the changeset viewer.