Changeset 1161

Timestamp:

11/03/11 05:37:52 (12 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:

• p1-messaging.xml (modified) (14 diffs)
• p2-semantics.xml (modified) (19 diffs)
• p3-payload.xml (modified) (2 diffs)
• p4-conditional.xml (modified) (4 diffs)

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -1405 +1405 @@
    because the associated response header fields (e.g., Transfer-Encoding,
    Content-Length, etc.) only indicate what their values would have been
-   if the method had been GET.  All 1xx (Informational), 204 (No Content),
+   if the request method had been GET.  All 1xx (Informational), 204 (No Content),
    and 304 (Not Modified) responses &MUST-NOT; include a message-body.
    All other responses do include a message-body, although the body
@@ -1604 +1604 @@
   <x:anchor-alias value="Method"/>
 <t>
-   The Method  token indicates the method to be performed on the
-   resource identified by the request-target. The method is case-sensitive.
+   The Method token indicates the request method to be performed on the
+   target resource. The request method is case-sensitive.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/>
@@ -1615 +1615 @@
   <x:anchor-alias value="request-target"/>
 <t>
-   The request-target identifies the resource upon which to apply the request.
+   The request-target identifies the target resource upon which to apply the request.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-target"/>
@@ -1630 +1630 @@
    The asterisk "*" ("asterisk form") means that the request does not apply to a
    particular resource, but to the server itself. This is only allowed for the
-   OPTIONS method. Thus, the only valid example is
+   OPTIONS request method. Thus, the only valid example is
 </t>
 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
@@ -1655 +1655 @@
 </t>
 <t><iref item="authority form (of request-target)"/>
-   The "authority form" is only used by the CONNECT method (&CONNECT;).
+   The "authority form" is only used by the CONNECT request method (&CONNECT;).
 </t>
 <t><iref item="path-absolute form (of request-target)"/>
@@ -1677 +1677 @@
 </t>
 <t>
-   If a proxy receives a request without any path in the request-target and
-   the method specified is capable of supporting the asterisk form of
-   request-target, then the last proxy on the request chain &MUST; forward the
-   request with "*" as the final request-target.
+   If a proxy receives an OPTIONS request without any path in the
+   request-target, then the last proxy on the request chain &MUST;
+   forward the request with "*" as the final request-target.
 </t>
 <figure><preamble>   
@@ -1688 +1687 @@
 </artwork></figure>
 <figure><preamble>   
-  would be forwarded by the proxy as
+  would be forwarded by the final proxy as
 </preamble><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
 OPTIONS * HTTP/1.1
@@ -2525 +2524 @@
 </t>
 <t>
-   Clients &SHOULD-NOT;  pipeline requests using non-idempotent methods or
-   non-idempotent sequences of methods (see &idempotent-methods;). Otherwise, a
+   Clients &SHOULD-NOT; pipeline requests using non-idempotent request methods or
+   non-idempotent sequences of request methods (see &idempotent-methods;). Otherwise, a
    premature termination of the transport connection could lead to
    indeterminate results. A client wishing to send a non-idempotent
@@ -2696 +2695 @@
    transport connection and retransmit the aborted sequence of requests
    without user interaction so long as the request sequence is
-   idempotent (see &idempotent-methods;). Non-idempotent methods or sequences
+   idempotent (see &idempotent-methods;). Non-idempotent request methods or sequences
    &MUST-NOT; be automatically retried, although user agents &MAY; offer a
    human operator the choice of retrying the request(s). Confirmation by
@@ -2804 +2803 @@
         code, it &MAY; close the transport connection or it &MAY; continue
         to read and discard the rest of the request.  It &MUST-NOT;
-        perform the requested method if it returns a final status code.
+        perform the request method if it returns a final status code.
     </t>
     <t> An origin server &SHOULD-NOT;  send a 100 (Continue) response if
@@ -3038 +3037 @@
    The "Content-Length" header field indicates the size of the
    message-body, in decimal number of octets, for any message other than
-   a response to the HEAD method or a response with a status code of 304.
-   In the case of responses to the HEAD method, it indicates the size of
-   the payload body (not including any potential transfer-coding) that
-   would have been sent had the request been a GET.
-   In the case of the 304 (Not Modified) response, it indicates the size of
-   the payload body (not including any potential transfer-coding) that
-   would have been sent in a 200 (OK) response.
+   a response to a HEAD request or a response with a status code of 304.
+   In the case of a response to a HEAD request, Content-Length indicates
+   the size of the payload body (not including any potential transfer-coding)
+   that would have been sent had the request been a GET.
+   In the case of a 304 (Not Modified) response to a GET request,
+   Content-Length indicates the size of the payload body (not including
+   any potential transfer-coding) that would have been sent in a 200 (OK)
+   response.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/><iref primary="true" item="Grammar" subitem="Content-Length-v"/>
@@ -3384 +3384 @@
    supported protocol while indicating to the server that it would like
    to use a "better" protocol if available (where "better" is determined
-   by the server, possibly according to the nature of the method and/or
-   resource being requested).
+   by the server, possibly according to the nature of the request method
+   or target resource).
 </t>
 <t>
@@ -4868 +4868 @@
    since 1990. The first version of HTTP, later referred to as HTTP/0.9,
    was a simple protocol for hypertext data transfer across the Internet
-   with only a single method and no metadata.
+   with only a single request method (GET) and no metadata.
    HTTP/1.0, as defined by <xref target="RFC1945"/>, added a range of request
    methods and MIME-like messaging that could include metadata about the data
@@ -5023 +5023 @@
   Update use of abs_path production from RFC 1808 to the path-absolute + query
   components of RFC 3986. State that the asterisk form is allowed for the OPTIONS
-  method only.
+  request method only.
   (<xref target="request-target"/>)
 </t>

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -430 +430 @@
   <x:anchor-alias value="extension-method"/>
 <t>
-   The Method token indicates the method to be performed on the target
+   The Method token indicates the request method to be performed on the target
    resource (&effective-request-uri;). The method is case-sensitive.
 </t>
@@ -468 +468 @@
 </texttable>
 <t>
-  Note that this list is not exhaustive &mdash; it does not include methods defined
+  Note that this list is not exhaustive &mdash; it does not include request methods defined
   in other specifications.
 </t>
@@ -811 +811 @@
 <section title="Method Definitions" anchor="method.definitions">
 <t>
-   The set of common methods for HTTP/1.1 is defined below. Although
+   The set of common request methods for HTTP/1.1 is defined below. Although
    this set can be expanded, additional methods cannot be assumed to
    share the same semantics for separately extended clients and servers.
@@ -828 +828 @@
 <t>
    In particular, the convention has been established that the GET, HEAD,
-   OPTIONS, and TRACE methods &SHOULD-NOT; have the significance of taking an action
-   other than retrieval. These methods ought to be considered "<x:dfn anchor="safe">safe</x:dfn>".
+   OPTIONS, and TRACE request methods &SHOULD-NOT; have the significance
+   of taking an action other than retrieval. These request methods ought
+   to be considered "<x:dfn anchor="safe">safe</x:dfn>".
    This allows user agents to represent other methods, such as POST, PUT
    and DELETE, in a special way, so that the user is made aware of the
@@ -846 +847 @@
 <iref item="Idempotent Methods" primary="true"/>
 <t>
-   Methods can also have the property of "idempotence" in that, aside
-   from error or expiration issues, the intended effect of multiple
+   Request methods can also have the property of "idempotence" in that,
+   aside from error or expiration issues, the intended effect of multiple
    identical requests is the same as for a single request.
-   The methods PUT, DELETE, and all safe methods are idempotent.
+   PUT, DELETE, and all safe request methods are idempotent.
    It is important to note that idempotence refers only to changes
    requested by the client: a server is free to change its state due
@@ -865 +866 @@
   <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/>
 <t>
-   The OPTIONS method represents a request for information about the
+   The OPTIONS method requests information about the
    communication options available on the request/response chain
-   identified by the effective request URI. This method allows the client to
+   identified by the effective request URI. This method allows a client to
    determine the options and/or requirements associated with a resource,
    or the capabilities of a server, without implying a resource action
@@ -873 +874 @@
 </t>
 <t>
-   Responses to this method are not cacheable.
+   Responses to the OPTIONS method are not cacheable.
 </t>
 <t>
@@ -924 +925 @@
   <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/>
 <t>
-   The GET method means retrieve whatever information (in the form of a
-   representation) currently corresponds to the target resource.
+   The GET method requests transfer of a current representation of
+   the target resource.
 </t>
 <t>   
@@ -937 +938 @@
    request message includes an If-Modified-Since, If-Unmodified-Since,
    If-Match, If-None-Match, or If-Range header field. A conditional GET
-   method requests that the representation be transferred only under the
+   requests that the representation be transferred only under the
    circumstances described by the conditional header field(s). The
-   conditional GET method is intended to reduce unnecessary network
+   conditional GET request is intended to reduce unnecessary network
    usage by allowing cached representations to be refreshed without requiring
    multiple requests or transferring data already held by the client.
@@ -947 +948 @@
    request message includes a Range header field. A partial GET requests
    that only part of the representation be transferred, as described in &header-range;.
-   The partial GET method is intended to reduce unnecessary
+   The partial GET request is intended to reduce unnecessary
    network usage by allowing partially-retrieved representations to be
    completed without transferring data already held by the client.
@@ -991 +992 @@
   <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/>
 <t>
-   The POST method is used to request that the origin server accept the
+   The POST method requests that the origin server accept the
    representation enclosed in the request as data to be processed by the 
    target resource. POST is designed to allow a uniform method to cover the
@@ -1047 +1048 @@
   <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/>
 <t>
-   The PUT method is used to request that the state of the target resource
+   The PUT method requests that the state of the target resource
    be created or replaced with the state defined by the representation
    enclosed in the request message payload.  A successful PUT of a given
@@ -1198 +1199 @@
   <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/>
 <t>
-   The TRACE method is used to invoke a remote, application-layer loop-back
+   The TRACE method requests a remote, application-layer loop-back
    of the request message. The final recipient of the request
    &SHOULD; reflect the message received back to the client as the
@@ -1227 +1228 @@
   <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/>
 <t>
-   The CONNECT method is used with a proxy to dynamically switch 
-   the connection to a tunnel.
-</t>
-<t>
-   When using CONNECT, the request-target &MUST; be use the authority form
-   (&request-target;); i.e., the host name and port number destination of the
-   requested connection separated by a colon:
+   The CONNECT method requests that the proxy establish a tunnel
+   to the request-target and then restrict its behavior to blind
+   forwarding of packets until the connection is closed.
+</t>
+<t>
+   When using CONNECT, the request-target &MUST; use the authority form
+   (&request-target;); i.e., the request-target consists of only the
+   host name and port number of the tunnel destination, separated by a colon.
+   For example,
 </t>
 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
@@ -2006 +2009 @@
   <iref primary="true" item="Status Codes" subitem="415 Unsupported Media Type" x:for-anchor=""/>
 <t>
-   The server is refusing to service the request because the representation of
-   the request is in a format not supported by the target resource
-   for the requested method.
+   The server is refusing to service the request because the request
+   payload is in a format not supported by this request method on the
+   target resource.
 </t>
 </section>
@@ -2170 +2173 @@
    The "Allow" response-header field lists the set of methods advertised as
    supported by the target resource. The purpose of this field is strictly to
-   inform the recipient of valid methods associated with the resource.
+   inform the recipient of valid request methods associated with the resource.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/><iref primary="true" item="Grammar" subitem="Allow-v"/>
@@ -2390 +2393 @@
 </t>
 <t>
-   The Max-Forwards header field &MAY; be ignored for all other methods.
+   The Max-Forwards header field &MAY; be ignored for all other request
+   methods.
 </t>
 </section>
@@ -2571 +2575 @@
 <section title="Method Registry" anchor="method.registration">
 <t>
-  The registration procedure for HTTP Methods is defined by 
+  The registration procedure for HTTP request methods is defined by 
   <xref target="method.registry"/> of this document.
 </t>
@@ -2976 +2980 @@
 </t>
 <t>
-   Some methods, like TRACE (<xref target="TRACE"/>), expose information
+   Some request methods, like TRACE (<xref target="TRACE"/>), expose information
    that was sent in request header fields within the body of their response. 
    Clients &SHOULD; be careful with sensitive information, like Cookies, 
-   Authorization credentials and other header fields that might be used to 
+   Authorization credentials, and other header fields that might be used to 
    collect data from the client.
 </t> 

draft-ietf-httpbis/latest/p3-payload.xml

@@ -1443 +1443 @@
    For a GET or HEAD request, this is the same as the default semantics
    when no Content-Location is provided by the server.  For a state-changing
-   method like PUT or POST, it implies that the server's response contains
+   request like PUT or POST, it implies that the server's response contains
    the new representation of that resource, thereby distinguishing it from
    representations that might only report about the action (e.g., "It worked!").
@@ -1460 +1460 @@
    contains a report on the action's status and the same report is
    available (for future access with GET) at the given URI.  For
-   example, a purchase transaction made via the POST method might
+   example, a purchase transaction made via a POST request might
    include a receipt document as the payload of the 200 response;
    the Content-Location value provides an identifier for retrieving

draft-ietf-httpbis/latest/p4-conditional.xml

@@ -802 +802 @@
    representation exists, the server &MUST-NOT; perform the requested method, and
    &MUST; return a 412 (Precondition Failed) response. This behavior is
-   most useful when the client wants to prevent an updating method, such
-   as PUT, from modifying a resource that has changed since the client
+   most useful when the client wants to prevent an updating request method,
+   such as PUT, from modifying a resource that has changed since the client
    last retrieved it.
 </t>
@@ -812 +812 @@
 </t>
 <t>
-   The meaning of "If-Match: *" is that the method &SHOULD; be performed
+   The meaning of "If-Match: *" is that the request method &SHOULD; be performed
    if the representation selected by the origin server (or by a cache,
    possibly using the Vary mechanism, see &header-vary;) exists, and
@@ -937 +937 @@
 <t>
    This allows efficient updates of cached information with a minimum amount of
-   transaction overhead. It is also used to prevent a method (e.g., PUT)
+   transaction overhead. It is also used to prevent a request method (e.g., PUT)
    from inadvertently modifying an existing resource when the client
    believes that the resource does not exist.
@@ -978 +978 @@
 </t>
 <t>
-   The meaning of "If-None-Match: *" is that the method &MUST-NOT; be
+   The meaning of "If-None-Match: *" is that the request method &MUST-NOT; be
    performed if the representation selected by the origin server (or by
    a cache, possibly using the Vary mechanism, see &header-vary;)