Ignore:
Timestamp:
Dec 15, 2012, 7:46:23 PM (7 years ago)
Author:
fielding@…
Message:

editorial fixes in methods; use send instead of return, sent instead of returned; partly addresses #419

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r2051 r2052  
    12571257      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="method.overview" href="#method.overview">Overview</a></h2>
    12581258      <p id="rfc.section.4.1.p.1">The request method token is the primary source of request semantics; it indicates the purpose for which the client has made
    1259          this request and what is expected by the client as a successful result. The request semantics <em class="bcp14">MAY</em> be further specialized by the semantics of some header fields when present in a request (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>) if those additional semantics do not conflict with the method.
     1259         this request and what is expected by the client as a successful result. The request semantics might be further specialized
     1260         by the semantics of some header fields when present in a request (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>) if those additional semantics do not conflict with the method.
    12601261      </p>
    12611262      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.15"></span>  <a href="#method.overview" class="smpl">method</a> = <a href="#imported.abnf" class="smpl">token</a>
    … …  
    12661267      </p>
    12671268      <p id="rfc.section.4.1.p.4">Unlike distributed objects, the standardized request methods in HTTP are not resource-specific, since uniform interfaces provide
    1268          for better visibility and reuse in network-based systems <a href="#REST" id="rfc.xref.REST.2"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>. Once defined, a standardized method <em class="bcp14">MUST</em> have the same semantics when applied to any resource, though each resource determines for itself whether those semantics are
    1269          implemented or allowed.
     1269         for better visibility and reuse in network-based systems <a href="#REST" id="rfc.xref.REST.2"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>. Once defined, a standardized method ought to have the same semantics when applied to any resource, though each resource
     1270         determines for itself whether those semantics are implemented or allowed.
    12701271      </p>
    12711272      <p id="rfc.section.4.1.p.5">This specification defines a number of standardized methods that are commonly used in HTTP, as outlined by the following table.
    … …  
    13261327         </table>
    13271328      </div>
    1328       <p id="rfc.section.4.1.p.6">The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>. When implemented, a server <em class="bcp14">MUST</em> implement the above methods according to the semantics defined for them in <a href="#method.definitions" title="Method Definitions">Section&nbsp;4.3</a>.
    1329       </p>
    1330       <p id="rfc.section.4.1.p.7">Additional methods <em class="bcp14">MAY</em> be used in HTTP; many have already been standardized outside the scope of this specification and ought to be registered within
    1331          the HTTP Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section&nbsp;8.1</a>.
     1329      <p id="rfc.section.4.1.p.6">All general-purpose servers <em class="bcp14">MUST</em> support the methods GET and HEAD. All other methods are <em class="bcp14">OPTIONAL</em>; when implemented, a server <em class="bcp14">MUST</em> implement the above methods according to the semantics defined for them in <a href="#method.definitions" title="Method Definitions">Section&nbsp;4.3</a>.
     1330      </p>
     1331      <p id="rfc.section.4.1.p.7">Additional methods, outside the scope of this specification, have been standardized for use in HTTP. All such methods ought
     1332         to be registered within the HTTP Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section&nbsp;8.1</a>.
    13321333      </p>
    13331334      <p id="rfc.section.4.1.p.8">The set of methods allowed by a target resource can be listed in an <a href="#header.allow" class="smpl">Allow</a> header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;7.4.1</a>). However, the set of allowed methods can change dynamically. When a request message is received that is unrecognized or
    … …  
    13491350         the Web will often have the side-effect of charging an advertising account.
    13501351      </p>
    1351       <p id="rfc.section.4.2.1.p.3">The GET, HEAD, OPTIONS, and TRACE request methods are defined to be safe.</p>
     1352      <p id="rfc.section.4.2.1.p.3">Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.</p>
    13521353      <p id="rfc.section.4.2.1.p.4">The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache
    13531354         performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply
    … …  
    13661367      <div id="rfc.iref.i.1"></div>
    13671368      <h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;<a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3>
    1368       <p id="rfc.section.4.2.2.p.1">Request methods are considered "<dfn id="idempotent">idempotent</dfn>" if the intended effect of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request
    1369          methods are idempotent.
     1369      <p id="rfc.section.4.2.2.p.1">Request methods are considered "<dfn id="idempotent">idempotent</dfn>" if the intended effect of multiple identical requests is the same as for a single request. Of the request methods defined
     1370         by this specification, the PUT, DELETE, and safe request methods are idempotent.
    13701371      </p>
    13711372      <p id="rfc.section.4.2.2.p.2">Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free
    … …  
    13901391      <div id="rfc.iref.g.16"></div>
    13911392      <p id="rfc.section.4.3.1.p.1">The GET method requests transfer of a current representation of the target resource.</p>
    1392       <p id="rfc.section.4.3.1.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation
    1393          in the response and not the source text of the process, unless that text happens to be the output of the process.
     1393      <p id="rfc.section.4.3.1.p.2">If the target resource is a data-producing process, the produced data will be sent as the representation, not the source text
     1394         of the process, unless that text happens to be the output of the process.
    13941395      </p>
    13951396      <p id="rfc.section.4.3.1.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional
    … …  
    14091410      <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h3>
    14101411      <div id="rfc.iref.h.1"></div>
    1411       <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
     1412      <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> send a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
    14121413         representation implied by the request without transferring the representation data. This method is often used for testing
    14131414         hypertext links for validity, accessibility, and recent modification.
    … …  
    14211422      <h3 id="rfc.section.4.3.3"><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;<a id="POST" href="#POST">POST</a></h3>
    14221423      <p id="rfc.section.4.3.3.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed
    1423          by the target resource. POST is designed to allow a uniform method to cover the following functions:
     1424         by the target resource. For example, POST is frequently used for the following functions (among others):
    14241425      </p>
    14251426      <ul>
    … …  
    14291430         <li>Extending a database through an append operation.</li>
    14301431      </ul>
    1431       <p id="rfc.section.4.3.3.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request
    1432          URI.
     1432      <p id="rfc.section.4.3.3.p.2">The actual function performed by the POST method is determined by the origin server and is usually dependent on the effective
     1433         request URI.
    14331434      </p>
    14341435      <p id="rfc.section.4.3.3.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> is the appropriate response status code, depending on whether or not the response includes a representation that describes
    14351436         the result.
    14361437      </p>
    1437       <p id="rfc.section.4.3.3.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;7.1.2</a>).
     1438      <p id="rfc.section.4.3.3.p.4">If one or more resources has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a>, contain a representation which describes the status of the request and refers to the new resource(s), and include a <a href="#header.location" class="smpl">Location</a> header field that provides an identifier for the primary resource created (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;7.1.2</a>).
    14381439      </p>
    14391440      <p id="rfc.section.4.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;3.1.4.2</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD (not POST) requests.
    … …  
    14451446      <p id="rfc.section.4.3.4.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation
    14461447         enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on
    1447          that same target resource will result in an equivalent representation being returned in a <a href="#status.200" class="smpl">200 (OK)</a> response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted
     1448         that same target resource will result in an equivalent representation being sent in a <a href="#status.200" class="smpl">200 (OK)</a> response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted
    14481449         upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent
    14491450         GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing
    … …  
    14531454         with the state of the enclosed representation, then either a <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
    14541455      </p>
    1455       <p id="rfc.section.4.3.4.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state).
     1456      <p id="rfc.section.4.3.4.p.3">An origin server <em class="bcp14">SHOULD</em> ignore unrecognized header fields received in a PUT request (i.e., do not save them as part of the resource state).
    14561457      </p>
    14571458      <p id="rfc.section.4.3.4.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot
    … …  
    15061507      <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h3>
    15071508      <div id="rfc.iref.d.2"></div>
    1508       <p id="rfc.section.4.3.5.p.1">The DELETE method requests that the origin server delete the target resource. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation
    1509          has been carried out, even if the status code returned from the origin server indicates that the action has been completed
    1510          successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible
    1511          location.
    1512       </p>
    1513       <p id="rfc.section.4.3.5.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes a representation describing the status, <a href="#status.202" class="smpl">202 (Accepted)</a> if the action has not yet been enacted, or <a href="#status.204" class="smpl">204 (No Content)</a> if the action has been enacted but the response does not include a representation.
    1514       </p>
    1515       <p id="rfc.section.4.3.5.p.3">A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause
     1509      <p id="rfc.section.4.3.5.p.1">The DELETE method requests that the origin server remove the association between the target resource and its current representations
     1510         or implementation. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI
     1511         mapping of the origin server, rather than an expectation that the information be deleted. The representations might or might
     1512         not be destroyed by the origin server, and the associated storage might or might not be reclaimed, depending entirely on the
     1513         nature of the resource and its implementation by the origin server (which are beyond the scope of this specification).
     1514      </p>
     1515      <p id="rfc.section.4.3.5.p.2">Relatively few resources allow the DELETE method — its primary use is for remote authoring environments, where the user has
     1516         some direction regarding its effect. For example, a resource that was previously created using a PUT request, or identified
     1517         via the Location header field after a <a href="#status.201" class="smpl">201 (Created)</a> response to a POST request, might allow a corresponding DELETE request to undo those actions. Similarly, custom user agent
     1518         implementations that implement an authoring function, such as revision control clients using HTTP for remote operations, might
     1519         use DELETE based on an assumption that the server's URI space has been crafted to correspond to a version repository.
     1520      </p>
     1521      <p id="rfc.section.4.3.5.p.3">If a DELETE method is successfully applied, the origin server <em class="bcp14">SHOULD</em> send a <a href="#status.202" class="smpl">202 (Accepted)</a> status code if the action seems okay but has not yet been enacted, or a <a href="#status.204" class="smpl">204 (No Content)</a> status code if the action has been enacted and no further information is to be supplied, or a <a href="#status.200" class="smpl">200 (OK)</a> status code if the action has been enacted and the response message includes a representation describing the status.
     1522      </p>
     1523      <p id="rfc.section.4.3.5.p.4">A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause
    15161524         some existing implementations to reject the request.
    15171525      </p>
    1518       <p id="rfc.section.4.3.5.p.4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses
     1526      <p id="rfc.section.4.3.5.p.5">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses
    15191527         for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    15201528      </p>
    15211529      <div id="rfc.iref.c.9"></div>
    15221530      <h3 id="rfc.section.4.3.6"><a href="#rfc.section.4.3.6">4.3.6</a>&nbsp;<a id="CONNECT" href="#CONNECT">CONNECT</a></h3>
    1523       <p id="rfc.section.4.3.6.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict
    1524          its behavior to blind forwarding of packets until the connection is closed.
    1525       </p>
    1526       <p id="rfc.section.4.3.6.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 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[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.
     1531      <p id="rfc.section.4.3.6.p.1">The CONNECT method is only applicable as a request to a proxy. A CONNECT requests that the recipient establish a tunnel to
     1532         the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind
     1533         forwarding of packets, in both directions, until the connection is closed.
     1534      </p>
     1535      <p id="rfc.section.4.3.6.p.2">A client sending a CONNECT request <em class="bcp14">MUST</em> send the authority form of request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[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.
    15271536         For example,
    15281537      </p>
    … …  
    15301539Host: server.example.com:80
    15311540
    1532 </pre><p id="rfc.section.4.3.6.p.4">Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the proxy has established a connection to the requested host and port, and has
    1533          switched to tunneling the current connection to that server connection. The tunneled data from the server begins immediately
    1534          after the blank line that concludes the successful response's header block.
     1541</pre><p id="rfc.section.4.3.6.p.4">The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another
     1542         proxy, by forwarding the CONNECT request to the next inbound proxy. Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the sender (and any inbound proxies) will switch to tunnel mode immediately after
     1543         the blank line that concludes the successful response's header block; data received after that blank line is from the server
     1544         identified by the request-target.
    15351545      </p>
    15361546      <p id="rfc.section.4.3.6.p.5">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response.
    … …  
    15391549         governed by HTTP.
    15401550      </p>
    1541       <p id="rfc.section.4.3.6.p.7">Proxy authentication might be used to establish the authority to create a tunnel:</p>
     1551      <p id="rfc.section.4.3.6.p.7">Proxy authentication might be used to establish the authority to create a tunnel. For example,</p>
    15421552      <div id="rfc.figure.u.19"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
    15431553Host: server.example.com:80
    … …  
    15471557         some existing implementations to reject the request.
    15481558      </p>
    1549       <p id="rfc.section.4.3.6.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded
    1550          if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding.
    1551       </p>
    1552       <p id="rfc.section.4.3.6.p.11">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case,
    1553          the first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any <a href="#status.2xx" class="smpl">2xx</a> status code unless it has either a direct or tunnel connection established to the authority.
    1554       </p>
    1555       <p id="rfc.section.4.3.6.p.12">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
    1556          the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that
    1557          peer undelivered, that data will be discarded.
    1558       </p>
    1559       <p id="rfc.section.4.3.6.p.13">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
     1559      <p id="rfc.section.4.3.6.p.10">When a tunnel intermediary detects that either side has closed its connection, any outstanding data that came from that side
     1560         will first be sent to the other side and then the intermediary will close both connections. If there is outstanding data left
     1561         undelivered, that data will be discarded.
     1562      </p>
     1563      <p id="rfc.section.4.3.6.p.11">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
    15601564      </p>
    15611565      <h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a>&nbsp;<a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3>
    … …  
    16831687      <p id="rfc.section.5.1.2.1.p.4">Requirements for HTTP/1.1 origin servers: </p>
    16841688      <ul>
    1685          <li>Upon receiving a request which includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> 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.
     1689         <li>Upon receiving a request which includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If the origin server responds with a final status code, it <em class="bcp14">MUST NOT</em> have performed the request method and <em class="bcp14">MAY</em> either close the connection or continue to read and discard the rest of the request.
    16861690         </li>
    16871691         <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility
    … …  
    23822386      <div id="rfc.iref.72"></div>
    23832387      <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a id="status.200" href="#status.200">200 OK</a></h3>
    2384       <p id="rfc.section.6.3.1.p.1">The request has succeeded. The payload returned with the response is dependent on the method used in the request, for example: </p>
     2388      <p id="rfc.section.6.3.1.p.1">The request has succeeded. The payload sent in the response is dependent on the method used in the request, for example: </p>
    23852389      <dl>
    23862390         <dt>GET</dt>
    … …  
    24022406         (e.g., in the case of a response to a PUT request).
    24032407      </p>
    2404       <p id="rfc.section.6.3.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.202" class="smpl">202 (Accepted)</a> response instead.
     2408      <p id="rfc.section.6.3.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before sending the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.202" class="smpl">202 (Accepted)</a> response instead.
    24052409      </p>
    24062410      <p id="rfc.section.6.3.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> response header field indicating the current value of the entity-tag for the representation of the resource identified by
    … …  
    24152419      <p id="rfc.section.6.3.3.p.2">The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process
    24162420         (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the
    2417          server persist until the process is completed. The representation returned with this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the
     2421         server persist until the process is completed. The representation sent with this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the
    24182422         user can expect the request to be fulfilled.
    24192423      </p>
    … …  
    24292433      <h3 id="rfc.section.6.3.5"><a href="#rfc.section.6.3.5">6.3.5</a>&nbsp;<a id="status.204" href="#status.204">204 No Content</a></h3>
    24302434      <p id="rfc.section.6.3.5.p.1">The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional
    2431          content to return in the response payload body. Metadata in the response header fields refer to the target resource and its
     2435         content to send in the response payload body. Metadata in the response header fields refer to the target resource and its
    24322436         current representation after the requested action.
    24332437      </p>
    … …  
    25142518      <div id="rfc.iref.73"></div>
    25152519      <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;<a id="status.301" href="#status.301">301 Moved Permanently</a></h3>
    2516       <p id="rfc.section.6.4.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the effective
    2517          request URI to one or more of the new references returned by the server, where possible.
     2520      <p id="rfc.section.6.4.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the enclosed URIs. Clients with link editing capabilities ought to automatically re-link references to the effective
     2521         request URI to one or more of the new references sent by the server, where possible.
    25182522      </p>
    25192523      <p id="rfc.section.6.4.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 301 responses.
    … …  
    26172621      </p>
    26182622      <div class="note" id="rfc.section.6.5.6.p.3">
    2619          <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept header fields sent in the
     2623         <p> <b>Note:</b> HTTP/1.1 servers are allowed to send responses which are not acceptable according to the accept header fields sent in the
    26202624            request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the
    26212625            header fields of an incoming response to determine if it is acceptable.
    … …  
    27372741      </p>
    27382742      <div class="note" id="rfc.section.6.6.5.p.2">
    2739          <p> <b>Note</b> to implementers: some deployed proxies are known to return <a href="#status.400" class="smpl">400 (Bad Request)</a> or <a href="#status.500" class="smpl">500 (Internal Server
     2743         <p> <b>Note</b> to implementers: some deployed proxies are known to send <a href="#status.400" class="smpl">400 (Bad Request)</a> or <a href="#status.500" class="smpl">500 (Internal Server
    27402744               Error)</a> when DNS lookups time out.
    27412745         </p>
Note: See TracChangeset for help on using the changeset viewer.