Ignore:
Timestamp:
Jan 10, 2013, 5:17:23 AM (7 years ago)
Author:
fielding@…
Message:

(editorial) add 1xx and 2xx definitions in prose; add description of payload in 200 response to unusual methods; clarify that ETag and Last-Modified provide metadata about the state of the selected representation at the conclusion of handling a response

File:
1 edited

Legend:

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

    r2104 r2105  
    23832383      <div id="rfc.iref.70"></div>
    23842384      <div id="rfc.iref.s.2"></div>
    2385       <p id="rfc.section.6.2.p.1">This class of status code indicates an interim response, consisting only of the status-line and optional header fields, and
    2386          is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did not
    2387          define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
    2388       </p>
    2389       <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a <a href="#status.100" class="smpl">100
    2390             (Continue)</a> status message. Unexpected 1xx status responses <em class="bcp14">MAY</em> be ignored by a user agent.
     2385      <p id="rfc.section.6.2.p.1">The <dfn>1xx (Informational)</dfn> class of status code indicates an interim response for communicating connection status or request progress prior to completing
     2386         the requested action and sending a final response. All 1xx responses consist of only the status-line and optional header fields,
     2387         and thus are terminated by the empty line at the end of the header block. There are no required header fields for this class
     2388         of status code. Since HTTP/1.0 did not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
     2389      </p>
     2390      <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a final response, even if the client does not expect a <a href="#status.100" class="smpl">100 (Continue)</a> status message. A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx status responses.
    23912391      </p>
    23922392      <p id="rfc.section.6.2.p.3">Proxies <em class="bcp14">MUST</em> forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself
    2393          requested the generation of the 1xx response. (For example, if a proxy adds an "Expect: 100-continue" field when it forwards
    2394          a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).)
     2393         requested the generation of the 1xx response. For example, if a proxy adds an "Expect: 100-continue" field when it forwards
     2394         a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).
    23952395      </p>
    23962396      <div id="rfc.iref.71"></div>
     
    24152415      <div id="rfc.iref.71"></div>
    24162416      <div id="rfc.iref.s.3"></div>
    2417       <p id="rfc.section.6.3.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p>
     2417      <p id="rfc.section.6.3.p.1">The <dfn>2xx (Successful)</dfn> class of status code indicates that the client's request was successfully received, understood, and accepted.
     2418      </p>
    24182419      <div id="rfc.iref.72"></div>
    24192420      <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>
    24202421      <p id="rfc.section.6.3.1.p.1">The <dfn>200 (OK)</dfn> status code indicates that the request has succeeded. The meaning of a payload sent in the response depends on the request
    2421          method, as follows:
     2422         method. For the methods defined by this specification, the payload can be summarized as:
    24222423      </p>
    24232424      <dl>
     
    24282429         <dd>the same representation as GET, but without the representation data;</dd>
    24292430         <dt>POST</dt>
    2430          <dd>a representation describing or containing the result of the action;</dd>
     2431         <dd>a representation of the status of, or results obtained from, the action;</dd>
     2432         <dt>PUT, DELETE</dt>
     2433         <dd>a representation of the status of the action;</dd>
     2434         <dt>OPTIONS</dt>
     2435         <dd>a representation of the communications options;</dd>
    24312436         <dt>TRACE</dt>
    2432          <dd>a representation containing the request message as received by the end server.</dd>
     2437         <dd>a representation of the request message as received by the end server.</dd>
    24332438      </dl>
    2434       <p id="rfc.section.6.3.1.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.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 200 responses.
     2439      <p id="rfc.section.6.3.1.p.2">Aside from responses to CONNECT, a 200 response always has a payload, though an origin server <em class="bcp14">MAY</em> generate a payload body of zero length. If no payload is desired, an origin server ought to send <dfn>204 (No Content)</dfn> instead. For CONNECT, no payload is allowed because the successful result is a tunnel, which begins immediately after the
     2440         200 response header block.
     2441      </p>
     2442      <p id="rfc.section.6.3.1.p.3">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.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 200 responses.
    24352443      </p>
    24362444      <div id="rfc.iref.72"></div>
    24372445      <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a id="status.201" href="#status.201">201 Created</a></h3>
    2438       <p id="rfc.section.6.3.2.p.1">The <dfn>201 (Created)</dfn> status code indicates that the request has been fulfilled and has resulted in one or more new resources being created.
    2439       </p>
    2440       <p id="rfc.section.6.3.2.p.2">Newly created resources are typically linked to from the response payload, with the most relevant URI also being carried in
    2441          the <a href="#header.location" class="smpl">Location</a> header field. If the newly created resource's URI is the same as the effective request URI, the Location field can be omitted.
    2442       </p>
    2443       <p id="rfc.section.6.3.2.p.3">If an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field is present in a 201 response, its field value is the entity-tag for the representation created, which is the
    2444          new representation of the resource identified by either the <a href="#header.location" class="smpl">Location</a> header field or, if no Location header field is received, by the effective request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>).
     2446      <p id="rfc.section.6.3.2.p.1">The <dfn>201 (Created)</dfn> status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. The
     2447         primary resource created by the request is identified by either a <a href="#header.location" class="smpl">Location</a> header field in the response or, if no <a href="#header.location" class="smpl">Location</a> field is received, by the effective request URI.
     2448      </p>
     2449      <p id="rfc.section.6.3.2.p.2">The 201 response payload typically describes and links to the resource(s) created. See <a href="#selected.representation" title="Selected Representation Header Fields">Section&nbsp;7.2</a> for discussion of the meaning and purpose of selected representation header fields, such as <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and Last-Modified, in a 201 response.
    24452450      </p>
    24462451      <div id="rfc.iref.72"></div>
     
    24752480         that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the
    24762481         user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or
    2477          updated metadata in the response to the active representation.
     2482         updated metadata in the response to its active representation.
    24782483      </p>
    24792484      <p id="rfc.section.6.3.5.p.4">For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that
     
    29942999      <div id="rfc.iref.s.7"></div>
    29953000      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="selected.representation" href="#selected.representation">Selected Representation Header Fields</a></h2>
    2996       <p id="rfc.section.7.2.p.1">We use the term "<dfn>selected representation</dfn>" to refer to the the current representation of the <a href="#resources" class="smpl">target resource</a> that would have been selected in a successful response if the same request had used the method GET and excluded any conditional
    2997          request header fields.
    2998       </p>
    2999       <p id="rfc.section.7.2.p.2">Additional header fields define metadata about the selected representation, which might differ from the representation included
    3000          in the message for responses to some state-changing methods. The following header fields are defined as selected representation
    3001          metadata:
     3001      <p id="rfc.section.7.2.p.1">We use the term "<dfn>selected representation</dfn>" to refer to the representation of the <a href="#resources" class="smpl">target resource</a> in a <a href="#status.200" class="smpl">200 (OK)</a> response to <a href="#GET" class="smpl">GET</a>, or the representation that would have been selected in a successful response if the request had used the method <a href="#GET" class="smpl">GET</a> and excluded any conditional request header fields.
     3002      </p>
     3003      <p id="rfc.section.7.2.p.2">The following header fields define metadata about the selected representation at the conclusion of handling the request. In
     3004         other words, for a successful response to a state-changing method, these fields describe the new representation that has replaced
     3005         the prior selected representation. For example, an ETag header field in a 201 response communicates the entity-tag of the
     3006         newly created resource's representation, so that it can be used in later conditional requests to prevent the "lost update"
     3007         problem <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    30023008      </p>
    30033009      <div id="rfc.table.u.11">
     
    44934499            </li>
    44944500            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    4495                   <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3.3</a>, <a href="#rfc.xref.GET.2">4.1</a>, <a href="#rfc.iref.g.16"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.3">8.1.3</a>, <a href="#rfc.xref.GET.4">B</a></li>
     4501                  <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3.3</a>, <a href="#rfc.xref.GET.2">4.1</a>, <a href="#rfc.iref.g.16"><b>4.3.1</b></a>, <a href="#rfc.extref.g.4">7.2</a>, <a href="#rfc.extref.g.5">7.2</a>, <a href="#rfc.xref.GET.3">8.1.3</a>, <a href="#rfc.xref.GET.4">B</a></li>
    44964502                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    44974503                     <ul>
     
    46124618                     </ul>
    46134619                  </li>
    4614                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.3.1</a>, <a href="#rfc.xref.Part4.2">5.2</a>, <a href="#rfc.xref.Part4.3">5.2</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">6.1</a>, <a href="#rfc.xref.Part4.8">6.1</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.3.2</a>, <a href="#rfc.xref.Part4.11">7.2</a>, <a href="#rfc.xref.Part4.12">7.2</a>, <a href="#rfc.xref.Part4.13">8.1.2</a>, <a href="#Part4"><b>11.1</b></a><ul>
     4620                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.3.1</a>, <a href="#rfc.xref.Part4.2">5.2</a>, <a href="#rfc.xref.Part4.3">5.2</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">6.1</a>, <a href="#rfc.xref.Part4.8">6.1</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">7.2</a>, <a href="#rfc.xref.Part4.11">7.2</a>, <a href="#rfc.xref.Part4.12">7.2</a>, <a href="#rfc.xref.Part4.13">8.1.2</a>, <a href="#Part4"><b>11.1</b></a><ul>
    46154621                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.12">7.2</a></li>
    4616                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.10">6.3.2</a>, <a href="#rfc.xref.Part4.11">7.2</a></li>
     4622                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.11">7.2</a></li>
    46174623                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">5.2</a></li>
    46184624                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">5.2</a></li>
Note: See TracChangeset for help on using the changeset viewer.