Ignore:
Timestamp:
10/01/13 13:17:23 (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.xml

    r2104 r2105  
    26332633  <iref primary="true" item="Status Codes Classes" subitem="1xx Informational" x:for-anchor=""/>
    26342634<t>
    2635    This class of status code indicates an interim response,
    2636    consisting only of the status-line and optional header fields, and is
    2637    terminated by an empty line. There are no required header fields for this
    2638    class of status code. Since HTTP/1.0 did not define any 1xx status
    2639    codes, servers &MUST-NOT; send a 1xx response to an HTTP/1.0 client
    2640    except under experimental conditions.
     2635   The <x:dfn>1xx (Informational)</x:dfn> class of status code indicates an
     2636   interim response for communicating connection status or request progress
     2637   prior to completing the requested action and sending a final response.
     2638   All 1xx responses consist of only the status-line and optional header
     2639   fields, and thus are terminated by the empty line at the end of the header
     2640   block. There are no required header fields for this class of status code.
     2641   Since HTTP/1.0 did not define any 1xx status codes, servers &MUST-NOT; send
     2642   a 1xx response to an HTTP/1.0 client except under experimental conditions.
    26412643</t>
    26422644<t>
    26432645   A client &MUST; be prepared to accept one or more 1xx status responses
    2644    prior to a regular response, even if the client does not expect a <x:ref>100
    2645    (Continue)</x:ref> status message. Unexpected 1xx status responses &MAY; be
    2646    ignored by a user agent.
     2646   prior to a final response, even if the client does not expect a
     2647   <x:ref>100 (Continue)</x:ref> status message.
     2648   A user agent &MAY; ignore unexpected 1xx status responses.
    26472649</t>
    26482650<t>
    26492651   Proxies &MUST; forward 1xx responses, unless the connection between the
    26502652   proxy and its client has been closed, or unless the proxy itself
    2651    requested the generation of the 1xx response. (For example, if a
     2653   requested the generation of the 1xx response. For example, if a
    26522654   proxy adds an "Expect: 100-continue" field when it forwards a request,
    26532655   then it need not forward the corresponding <x:ref>100 (Continue)</x:ref>
    2654    response(s).)
     2656   response(s).
    26552657</t>
    26562658
     
    27062708  <iref primary="true" item="Status Codes Classes" subitem="2xx Successful" x:for-anchor=""/>
    27072709<t>
    2708    This class of status code indicates that the client's request was
    2709    successfully received, understood, and accepted.
     2710   The <x:dfn>2xx (Successful)</x:dfn> class of status code indicates that
     2711   the client's request was successfully received, understood, and accepted.
    27102712</t>
    27112713
     
    27162718   The <x:dfn>200 (OK)</x:dfn> status code indicates that the request has
    27172719   succeeded. The meaning of a payload sent in the response depends on the
    2718    request method, as follows:
     2720   request method. For the methods defined by this specification, the payload
     2721   can be summarized as:
    27192722  <list style="hanging">
    27202723    <t hangText="GET">
     
    27252728    </t>
    27262729    <t hangText="POST">
    2727       a representation describing or containing the result of the action;
     2730      a representation of the status of, or results obtained from, the action;
     2731    </t>
     2732    <t hangText="PUT, DELETE">
     2733      a representation of the status of the action;
     2734    </t>
     2735    <t hangText="OPTIONS">
     2736      a representation of the communications options;
    27282737    </t>
    27292738    <t hangText="TRACE">
    2730       a representation containing the request message as received by the
     2739      a representation of the request message as received by the
    27312740      end server.
    27322741    </t>
     
    27342743</t>
    27352744<t>
     2745   Aside from responses to CONNECT, a 200 response always has a payload,
     2746   though an origin server &MAY; generate a payload body of zero length.
     2747   If no payload is desired, an origin server ought to send
     2748   <x:dfn>204 (No Content)</x:dfn> instead.
     2749   For CONNECT, no payload is allowed because the successful result is a
     2750   tunnel, which begins immediately after the 200 response header block.
     2751</t>
     2752<t>
    27362753   Caches &MAY; use a heuristic (see &p6-heuristic;) to determine
    27372754   freshness for 200 responses.
     
    27442761<t>
    27452762   The <x:dfn>201 (Created)</x:dfn> status code indicates that the request has
    2746    been fulfilled and has resulted in one or more new resources being created.
    2747 </t>
    2748 <t>
    2749    Newly created resources are typically linked to from the response payload,
    2750    with the most relevant URI also being carried in the <x:ref>Location</x:ref>
    2751    header field. If the newly created resource's URI is the same as the
    2752    effective request URI, the Location field can be omitted.
    2753 </t>
    2754 <t>
    2755    If an <x:ref>ETag</x:ref> header field is present in a 201 response, its
    2756    field value is the entity-tag for the representation created, which
    2757    is the new representation of the resource identified by either the
    2758    <x:ref>Location</x:ref> header field or, if no Location header field
    2759    is received, by the effective request URI (see &header-etag;).
     2763   been fulfilled and has resulted in one or more new resources being created.
     2764   The primary resource created by the request is identified by either a
     2765   <x:ref>Location</x:ref> header field in the response or, if no
     2766   <x:ref>Location</x:ref> field is received, by the effective request URI.
     2767</t>
     2768<t>
     2769   The 201 response payload typically describes and links to the resource(s)
     2770   created. See <xref target="selected.representation"/> for discussion of the
     2771   meaning and purpose of selected representation header fields, such as
     2772   <x:ref>ETag</x:ref> and <x:ref>Last-Modified</x:ref>, in a 201 response.
    27602773</t>
    27612774</section>
     
    28262839   (if any).  The server assumes that the user agent will provide some
    28272840   indication of the success to its user, in accord with its own interface,
    2828    and apply any new or updated metadata in the response to the active
     2841   and apply any new or updated metadata in the response to its active
    28292842   representation.
    28302843</t>
     
    38593872<t>
    38603873   We use the term "<x:dfn>selected representation</x:dfn>" to refer to the
    3861    the current representation of the <x:ref>target resource</x:ref> that would have been
    3862    selected in a successful response if the same request had used the
    3863    method GET and excluded any conditional request header fields.
    3864 </t>
    3865 <t>
    3866    Additional header fields define metadata about the selected
    3867    representation, which might differ from the representation included
    3868    in the message for responses to some state-changing methods.
    3869    The following header fields are defined as selected representation
    3870    metadata:
     3874   representation of the <x:ref>target resource</x:ref> in a
     3875   <x:ref>200 (OK)</x:ref> response to <x:ref>GET</x:ref>, or the
     3876   representation that would have been selected in a successful response if
     3877   the request had used the method <x:ref>GET</x:ref> and excluded any
     3878   conditional request header fields.
     3879</t>
     3880<t>
     3881   The following header fields define metadata about the selected
     3882   representation at the conclusion of handling the request. In other words,
     3883   for a successful response to a state-changing method, these fields describe
     3884   the new representation that has replaced the prior selected representation.
     3885   For example, an ETag header field in a 201 response communicates the
     3886   entity-tag of the newly created resource's representation, so that it can
     3887   be used in later conditional requests to prevent the "lost update"
     3888   problem <xref target="Part4"/>.
    38713889</t>
    38723890<texttable align="left">
Note: See TracChangeset for help on using the changeset viewer.