Changeset 1162


Ignore:
Timestamp:
Mar 10, 2011, 9:42:12 PM (9 years ago)
Author:
fielding@…
Message:

update generated HTML

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

Legend:

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

    r1159 r1162  
    12911291      <p id="rfc.section.3.3.p.8">For response messages, whether or not a message-body is included with a message is dependent on both the request method and
    12921292         the response status code (<a href="#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section&nbsp;5.1.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g.,
    1293          Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the method had been GET. All 1xx
    1294          (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length.
     1293         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET.
     1294         All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length.
    12951295      </p>
    12961296      <p id="rfc.section.3.3.p.9">The length of the message-body is determined by one of the following (in order of precedence):</p>
     
    14321432      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.46"></span>  <a href="#request-line" class="smpl">Request-Line</a>   = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>
    14331433</pre><h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a>&nbsp;<a id="method" href="#method">Method</a></h3>
    1434       <p id="rfc.section.4.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. The method is case-sensitive.</p>
     1434      <p id="rfc.section.4.1.1.p.1">The Method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>
    14351435      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.47"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    14361436</pre><h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a id="request-target" href="#request-target">request-target</a></h3>
    1437       <p id="rfc.section.4.1.2.p.1">The request-target identifies the resource upon which to apply the request.</p>
     1437      <p id="rfc.section.4.1.2.p.1">The request-target identifies the target resource upon which to apply the request.</p>
    14381438      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.48"></span>  <a href="#request-target" class="smpl">request-target</a> = "*"
    14391439                 / <a href="#uri" class="smpl">absolute-URI</a>
     
    14421442</pre><p id="rfc.section.4.1.2.p.3">The four options for request-target are dependent on the nature of the request.</p>
    14431443      <p id="rfc.section.4.1.2.p.4"><span id="rfc.iref.a.1"></span> The asterisk "*" ("asterisk form") means that the request does not apply to a particular resource, but to the server itself.
    1444          This is only allowed for the OPTIONS method. Thus, the only valid example is
     1444         This is only allowed for the OPTIONS request method. Thus, the only valid example is
    14451445      </p>
    14461446      <div id="rfc.figure.u.34"></div><pre class="text2">OPTIONS * HTTP/1.1
     
    14531453</pre><p id="rfc.section.4.1.2.p.8">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
    14541454      </p>
    1455       <p id="rfc.section.4.1.2.p.9"><span id="rfc.iref.a.3"></span> The "authority form" is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1455      <p id="rfc.section.4.1.2.p.9"><span id="rfc.iref.a.3"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    14561456      </p>
    14571457      <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.p.2"></span> The most common form of request-target is that used to identify a resource on an origin server or gateway ("path-absolute
     
    14641464         URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
    14651465      </p>
    1466       <p id="rfc.section.4.1.2.p.13">If a proxy receives a request without any path in the request-target and the method specified is capable of supporting the
    1467          asterisk form of request-target, then the last proxy on the request chain <em class="bcp14">MUST</em> forward the request with "*" as the final request-target.
     1466      <p id="rfc.section.4.1.2.p.13">If a proxy receives an OPTIONS request without any path in the request-target, then the last proxy on the request chain <em class="bcp14">MUST</em> forward the request with "*" as the final request-target.
    14681467      </p>
    14691468      <div id="rfc.figure.u.37"></div>
    14701469      <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1
    14711470</pre><div id="rfc.figure.u.38"></div>
    1472       <p>would be forwarded by the proxy as</p><pre class="text2">OPTIONS * HTTP/1.1
     1471      <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1
    14731472Host: www.example.org:8001
    14741473</pre>  <p>after connecting to port 8001 of host "www.example.org".</p>
     
    18901889      <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    18911890      </p>
    1892       <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     1891      <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    18931892         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    18941893      </p>
     
    19741973      </p>
    19751974      <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    1976          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
     1975         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
    19771976         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
    19781977      </p>
     
    20212020      <ul>
    20222021         <li>Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status
    2023             code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the requested method if it returns a final status code.
     2022            code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
    20242023         </li>
    20252024         <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue"
     
    21342133      <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h2>
    21352134      <p id="rfc.section.9.2.p.1">The "Content-Length" header field indicates the size of the message-body, in decimal number of octets, for any message other
    2136          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
     2135         than 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
    21372136         indicates the size of the payload body (not including any potential transfer-coding) that would have been sent had the request
    2138          been a GET. In the case of the 304 (Not Modified) response, it indicates the size of the payload body (not including any potential
    2139          transfer-coding) that would have been sent in a 200 (OK) response.
     2137         been a GET. In the case of a 304 (Not Modified) response to a GET request, Content-Length indicates the size of the payload
     2138         body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response.
    21402139      </p>
    21412140      <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span>  <a href="#header.content-length" class="smpl">Content-Length</a>   = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>
     
    23102309         transition between incompatible protocols by allowing the client to initiate a request in the more commonly supported protocol
    23112310         while indicating to the server that it would like to use a "better" protocol if available (where "better" is determined by
    2312          the server, possibly according to the nature of the method and/or resource being requested).
     2311         the server, possibly according to the nature of the request method or target resource).
    23132312      </p>
    23142313      <p id="rfc.section.9.8.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
     
    29992998      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
    30002999      <p id="rfc.section.B.p.1">HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, later referred
    3001          to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single method and no metadata.
    3002          HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, added a range of request methods and MIME-like messaging that could include metadata about the data transferred and modifiers
     3000         to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single request method (GET)
     3001         and no metadata. HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, added a range of request methods and MIME-like messaging that could include metadata about the data transferred and modifiers
    30033002         on the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration the effects of hierarchical
    30043003         proxies, caching, the need for persistent connections, or name-based virtual hosts. The proliferation of incompletely-implemented
     
    30843083      </p>
    30853084      <p id="rfc.section.B.3.p.7">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk
    3086          form is allowed for the OPTIONS method only. (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>)
     3085         form is allowed for the OPTIONS request method only. (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>)
    30873086      </p>
    30883087      <p id="rfc.section.B.3.p.8">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1160 r1162  
    774774             &lt;WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a>&gt;
    775775</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
    776       <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
     776      <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
    777777      </p>
    778778      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#core.rules" class="smpl">token</a>
     
    829829         </table>
    830830      </div>
    831       <p id="rfc.section.2.1.p.2">Note that this list is not exhaustive — it does not include methods defined in other specifications.</p>
     831      <p id="rfc.section.2.1.p.2">Note that this list is not exhaustive — it does not include request methods defined in other specifications.</p>
    832832      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="method.registry" href="#method.registry">Method Registry</a></h2>
    833833      <p id="rfc.section.2.2.p.1">The HTTP Method Registry defines the name space for the Method token in the Request line of an HTTP request.</p>
     
    13091309      </p>
    13101310      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="method.definitions" href="#method.definitions">Method Definitions</a></h1>
    1311       <p id="rfc.section.7.p.1">The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed
    1312          to share the same semantics for separately extended clients and servers.
     1311      <p id="rfc.section.7.p.1">The set of common request methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot
     1312         be assumed to share the same semantics for separately extended clients and servers.
    13131313      </p>
    13141314      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>
     
    13181318         the user to be aware of any actions they take which might have an unexpected significance to themselves or others.
    13191319      </p>
    1320       <p id="rfc.section.7.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is
     1320      <p id="rfc.section.7.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE request methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These request methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is
    13211321         made aware of the fact that a possibly unsafe action is being requested.
    13221322      </p>
     
    13271327      <div id="rfc.iref.i.1"></div>
    13281328      <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3>
    1329       <p id="rfc.section.7.1.2.p.1">Methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect of
    1330          multiple identical requests is the same as for a single request. The methods PUT, DELETE, and all safe methods are idempotent.
     1329      <p id="rfc.section.7.1.2.p.1">Request methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect
     1330         of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request methods are idempotent.
    13311331         It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state
    13321332         due to multiple requests for the purpose of tracking those requests, versioning of results, etc.
     
    13351335      <div id="rfc.iref.o.1"></div>
    13361336      <div id="rfc.iref.m.1"></div>
    1337       <p id="rfc.section.7.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response
    1338          chain identified by the effective request URI. This method allows the client to determine the options and/or requirements
    1339          associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
    1340       </p>
    1341       <p id="rfc.section.7.2.p.2">Responses to this method are not cacheable.</p>
     1337      <p id="rfc.section.7.2.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified
     1338         by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource,
     1339         or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
     1340      </p>
     1341      <p id="rfc.section.7.2.p.2">Responses to the OPTIONS method are not cacheable.</p>
    13421342      <p id="rfc.section.7.2.p.3">If the OPTIONS request includes a message-body (as indicated by the presence of Content-Length or Transfer-Encoding), then
    13431343         the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions
     
    13611361      <div id="rfc.iref.g.5"></div>
    13621362      <div id="rfc.iref.m.2"></div>
    1363       <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the target resource.</p>
     1363      <p id="rfc.section.7.3.p.1">The GET method requests transfer of a current representation of the target resource.</p>
    13641364      <p id="rfc.section.7.3.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation
    13651365         in the response and not the source text of the process, unless that text happens to be the output of the process.
    13661366      </p>
    13671367      <p id="rfc.section.7.3.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since,
    1368          If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the representation be transferred
    1369          only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce
    1370          unnecessary network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring
    1371          data already held by the client.
     1368         If-Match, If-None-Match, or If-Range header field. A conditional GET requests that the representation be transferred only
     1369         under the circumstances described by the conditional header field(s). The conditional GET request is intended to reduce unnecessary
     1370         network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring data
     1371         already held by the client.
    13721372      </p>
    13731373      <p id="rfc.section.7.3.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial
    1374          GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved representations to
    1375          be completed without transferring data already held by the client.
     1374         GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations
     1375         to be completed without transferring data already held by the client.
    13761376      </p>
    13771377      <p id="rfc.section.7.3.p.5">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     
    13931393      <div id="rfc.iref.m.4"></div>
    13941394      <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2>
    1395       <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the representation enclosed in the request as data to be
    1396          processed by the target resource. POST is designed to allow a uniform method to cover the following functions:
     1395      <p id="rfc.section.7.5.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed
     1396         by the target resource. POST is designed to allow a uniform method to cover the following functions:
    13971397      </p>
    13981398      <ul>
     
    14201420      <div id="rfc.iref.m.5"></div>
    14211421      <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h2>
    1422       <p id="rfc.section.7.6.p.1">The PUT method is used to request that the state of the target resource be created or replaced with the state defined by the
    1423          representation enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent
    1424          GET on that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However,
    1425          there is no guarantee that such a state change will be observable, since the target resource might be acted upon by other
    1426          user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received.
    1427          A successful response only implies that the user agent's intent was achieved at the time of its processing by the origin server.
     1422      <p id="rfc.section.7.6.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation
     1423         enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on
     1424         that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there
     1425         is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents
     1426         in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful
     1427         response only implies that the user agent's intent was achieved at the time of its processing by the origin server.
    14281428      </p>
    14291429      <p id="rfc.section.7.6.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that
     
    14941494      <div id="rfc.iref.t.1"></div>
    14951495      <div id="rfc.iref.m.7"></div>
    1496       <p id="rfc.section.7.8.p.1">The TRACE method is used to invoke a remote, application-layer loop-back of the request message. The final recipient of the
    1497          request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message-body of a 200 (OK) response. The final recipient is either
     1496      <p id="rfc.section.7.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message-body of a 200 (OK) response. The final recipient is either
    14981497         the origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section&nbsp;9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body.
    14991498      </p>
     
    15081507      <div id="rfc.iref.m.8"></div>
    15091508      <h2 id="rfc.section.7.9"><a href="#rfc.section.7.9">7.9</a>&nbsp;<a id="CONNECT" href="#CONNECT">CONNECT</a></h2>
    1510       <p id="rfc.section.7.9.p.1">The CONNECT method is used with a proxy to dynamically switch the connection to a tunnel.</p>
    1511       <p id="rfc.section.7.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> be use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 4.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the host name and port number destination of the requested connection separated by a colon:
     1509      <p id="rfc.section.7.9.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and then restrict its behavior to blind
     1510         forwarding of packets until the connection is closed.
     1511      </p>
     1512      <p id="rfc.section.7.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 4.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
     1513         For example,
    15121514      </p>
    15131515      <div id="rfc.figure.u.10"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
     
    18901892      <div id="rfc.iref.s.34"></div>
    18911893      <h3 id="rfc.section.8.4.16"><a href="#rfc.section.8.4.16">8.4.16</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>
    1892       <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the representation of the request is in a format not supported by the
    1893          target resource for the requested method.
     1894      <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the request payload is in a format not supported by this request method
     1895         on the target resource.
    18941896      </p>
    18951897      <div id="rfc.iref.55"></div>
     
    19721974      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h2>
    19731975      <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the target resource. The purpose of
    1974          this field is strictly to inform the recipient of valid methods associated with the resource.
     1976         this field is strictly to inform the recipient of valid request methods associated with the resource.
    19751977      </p>
    19761978      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span>  <a href="#header.allow" class="smpl">Allow</a>   = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a>
     
    20732075      <p id="rfc.section.9.5.p.4">Each proxy or gateway recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).
    20742076      </p>
    2075       <p id="rfc.section.9.5.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other methods.
     2077      <p id="rfc.section.9.5.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.
    20762078      </p>
    20772079      <div id="rfc.iref.r.1"></div>
     
    21582160</pre><h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    21592161      <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="method.registration" href="#method.registration">Method Registry</a></h2>
    2160       <p id="rfc.section.10.1.p.1">The registration procedure for HTTP Methods is defined by <a href="#method.registry" title="Method Registry">Section&nbsp;2.2</a> of this document.
     2162      <p id="rfc.section.10.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section&nbsp;2.2</a> of this document.
    21612163      </p>
    21622164      <p id="rfc.section.10.1.p.2">The HTTP Method Registry shall be created at &lt;<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>&gt; and be populated with the registrations below:
     
    25822584         to uniquely identify the user.
    25832585      </p>
    2584       <p id="rfc.section.11.1.p.9">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other header fields that might be used
     2586      <p id="rfc.section.11.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used
    25852587         to collect data from the client.
    25862588      </p>
  • draft-ietf-httpbis/latest/p3-payload.html

    r1154 r1162  
    359359  }
    360360  @bottom-center {
    361        content: "Expires September 10, 2011";
     361       content: "Expires September 11, 2011";
    362362  }
    363363  @bottom-right {
     
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-03-09">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-03-10">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    412412      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
     
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: September 10, 2011</td>
     436               <td class="left">Expires: September 11, 2011</td>
    437437               <td class="right">J. Mogul</td>
    438438            </tr>
     
    491491            <tr>
    492492               <td class="left"></td>
    493                <td class="right">March 9, 2011</td>
     493               <td class="right">March 10, 2011</td>
    494494            </tr>
    495495         </tbody>
     
    517517         in progress”.
    518518      </p>
    519       <p>This Internet-Draft will expire on September 10, 2011.</p>
     519      <p>This Internet-Draft will expire on September 11, 2011.</p>
    520520      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    521521      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    13291329      <p id="rfc.section.6.7.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response
    13301330         payload <em class="bcp14">SHOULD</em> be considered the current representation of that resource. For a GET or HEAD request, this is the same as the default semantics
    1331          when no Content-Location is provided by the server. For a state-changing method like PUT or POST, it implies that the server's
     1331         when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's
    13321332         response contains the new representation of that resource, thereby distinguishing it from representations that might only
    13331333         report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the
     
    13391339         and the representation selected for this response can also be found at the identified URI. For other methods, such a Content-Location
    13401340         indicates that this representation contains a report on the action's status and the same report is available (for future access
    1341          with GET) at the given URI. For example, a purchase transaction made via the POST method might include a receipt document
    1342          as the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt
     1341         with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as
     1342         the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt
    13431343         in the future.
    13441344      </p>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r1155 r1162  
    359359  }
    360360  @bottom-center {
    361        content: "Expires September 10, 2011";
     361       content: "Expires September 11, 2011";
    362362  }
    363363  @bottom-right {
     
    406406      <meta name="dct.creator" content="Reschke, J. F.">
    407407      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    408       <meta name="dct.issued" scheme="ISO8601" content="2011-03-09">
     408      <meta name="dct.issued" scheme="ISO8601" content="2011-03-10">
    409409      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    410410      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
     
    432432            </tr>
    433433            <tr>
    434                <td class="left">Expires: September 10, 2011</td>
     434               <td class="left">Expires: September 11, 2011</td>
    435435               <td class="right">J. Mogul</td>
    436436            </tr>
     
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">March 9, 2011</td>
     491               <td class="right">March 10, 2011</td>
    492492            </tr>
    493493         </tbody>
     
    515515         in progress”.
    516516      </p>
    517       <p>This Internet-Draft will expire on September 10, 2011.</p>
     517      <p>This Internet-Draft will expire on September 11, 2011.</p>
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    519519      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    939939         for that resource, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist.
    940940      </p>
    941       <p id="rfc.section.6.2.p.5">If none of the entity-tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,
    942          such as PUT, from modifying a resource that has changed since the client last retrieved it.
     941      <p id="rfc.section.6.2.p.5">If none of the entity-tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating request
     942         method, such as PUT, from modifying a resource that has changed since the client last retrieved it.
    943943      </p>
    944944      <p id="rfc.section.6.2.p.6">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status code, then the
    945945         If-Match header field <em class="bcp14">MUST</em> be ignored.
    946946      </p>
    947       <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
     947      <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the request method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
    948948      </p>
    949949      <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the representation corresponding to the If-Match value (a single entity-tag) is no longer a representation of
     
    10151015      </p>
    10161016      <p id="rfc.section.6.4.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent
    1017          a method (e.g., PUT) from inadvertently modifying an existing resource when the client believes that the resource does not
    1018          exist.
     1017         a request method (e.g., PUT) from inadvertently modifying an existing resource when the client believes that the resource
     1018         does not exist.
    10191019      </p>
    10201020      <p id="rfc.section.6.4.p.3">As a special case, the value "*" matches any current representation of the resource.</p>
     
    10321032         the If-None-Match header field <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section&nbsp;5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
    10331033      </p>
    1034       <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
     1034      <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the request method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
    10351035      </p>
    10361036      <p id="rfc.section.6.4.p.9">Examples:</p>
  • draft-ietf-httpbis/latest/p5-range.html

    r1155 r1162  
    359359  }
    360360  @bottom-center {
    361        content: "Expires September 10, 2011";
     361       content: "Expires September 11, 2011";
    362362  }
    363363  @bottom-right {
     
    406406      <meta name="dct.creator" content="Reschke, J. F.">
    407407      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    408       <meta name="dct.issued" scheme="ISO8601" content="2011-03-09">
     408      <meta name="dct.issued" scheme="ISO8601" content="2011-03-10">
    409409      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    410410      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
     
    432432            </tr>
    433433            <tr>
    434                <td class="left">Expires: September 10, 2011</td>
     434               <td class="left">Expires: September 11, 2011</td>
    435435               <td class="right">J. Mogul</td>
    436436            </tr>
     
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">March 9, 2011</td>
     491               <td class="right">March 10, 2011</td>
    492492            </tr>
    493493         </tbody>
     
    515515         in progress”.
    516516      </p>
    517       <p>This Internet-Draft will expire on September 10, 2011.</p>
     517      <p>This Internet-Draft will expire on September 11, 2011.</p>
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    519519      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
  • draft-ietf-httpbis/latest/p6-cache.html

    r1155 r1162  
    362362  }
    363363  @bottom-center {
    364        content: "Expires September 10, 2011";
     364       content: "Expires September 11, 2011";
    365365  }
    366366  @bottom-right {
     
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-03-09">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-03-10">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    412412      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: September 10, 2011</td>
     436               <td class="left">Expires: September 11, 2011</td>
    437437               <td class="right">J. Mogul</td>
    438438            </tr>
     
    495495            <tr>
    496496               <td class="left"></td>
    497                <td class="right">March 9, 2011</td>
     497               <td class="right">March 10, 2011</td>
    498498            </tr>
    499499         </tbody>
     
    521521         in progress”.
    522522      </p>
    523       <p>This Internet-Draft will expire on September 10, 2011.</p>
     523      <p>This Internet-Draft will expire on September 11, 2011.</p>
    524524      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    525525      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
  • draft-ietf-httpbis/latest/p7-auth.html

    r1155 r1162  
    359359  }
    360360  @bottom-center {
    361        content: "Expires September 10, 2011";
     361       content: "Expires September 11, 2011";
    362362  }
    363363  @bottom-right {
     
    403403      <meta name="dct.creator" content="Reschke, J. F.">
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    405       <meta name="dct.issued" scheme="ISO8601" content="2011-03-09">
     405      <meta name="dct.issued" scheme="ISO8601" content="2011-03-10">
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    407407      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication.">
     
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: September 10, 2011</td>
     436               <td class="left">Expires: September 11, 2011</td>
    437437               <td class="right">HP</td>
    438438            </tr>
     
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">March 9, 2011</td>
     489               <td class="right">March 10, 2011</td>
    490490            </tr>
    491491         </tbody>
     
    513513         in progress”.
    514514      </p>
    515       <p>This Internet-Draft will expire on September 10, 2011.</p>
     515      <p>This Internet-Draft will expire on September 11, 2011.</p>
    516516      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    517517      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset for help on using the changeset viewer.