Ignore:
Timestamp:
Jul 19, 2010, 4:52:07 AM (9 years ago)
Author:
fielding@…
Message:

Addresses #69: Clarify "Requested Variant"
Addresses #109: Clarify entity / representation / variant terminology

Replaced entity with payload and variant with representation.
Cleaned up description of 204 status code (related to ticket #22)
Rewrote section on Content-Location and refer to def in RFC2557.

Addresses #110: Clarify rules for determining what entities a response carries

Detail the rules for Content-Location and remove the cross-ref.

Addresses #167: Content-Location on 304 responses

Removed sentence in C-Loc that refers to using C-Loc to select a

variant from cache (an already removed "feature")

Addresses #136: confusing req. language for Content-Location

Removed the confusing paragraph because HTTP does not know
anything about variants behind the resource interface and
thus cannot make this an interop requirement. In any case,
it only existed to support the already removed cache feature
that nobody implemented.

Addresses #80: Content-Location isn't special

Clarifies that C-Loc is representation metadata and what
(not) to do with it if received on a request.

File:
1 edited

Legend:

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

    r848 r856  
    11851185   The request has been fulfilled and has resulted in a new resource being
    11861186   created. The newly created resource can be referenced by the URI(s)
    1187    returned in the entity of the response, with the most specific URI
     1187   returned in the payload of the response, with the most specific URI
    11881188   for the resource given by a Location header field. The response
    1189    &SHOULD; include an entity containing a list of resource
     1189   &SHOULD; include a payload containing a list of resource
    11901190   characteristics and location(s) from which the user or user agent can
    1191    choose the one most appropriate. The entity format is specified by
     1191   choose the one most appropriate. The payload format is specified by
    11921192   the media type given in the Content-Type header field. The origin
    11931193   server &MUST; create the resource before returning the 201 status code.
     
    11971197<t>
    11981198   A 201 response &MAY; contain an ETag response header field indicating
    1199    the current value of the entity tag for the requested variant just
    1200    created, see &header-etag;.
     1199   the current value of the entity tag for the representation of the resource
     1200   just created (see &header-etag;).
    12011201</t>
    12021202</section>
     
    12431243  <iref primary="true" item="Status Codes" subitem="204 No Content" x:for-anchor=""/>
    12441244<t>
    1245    The server has fulfilled the request but does not need to return an
    1246    entity-body, and might want to return updated metainformation. The
    1247    response &MAY; include new or updated metainformation in the form of
    1248    entity-headers, which if present &SHOULD; be associated with the
    1249    requested variant.
    1250 </t>
    1251 <t>
    1252    If the client is a user agent, it &SHOULD-NOT;  change its document view
     1245   The server has successfully fulfilled the request, but there is no
     1246   additional content to return in the response payload body.  The
     1247   resource metadata and representation metadata in the response message's
     1248   header fields refer to the requested resource and its current
     1249   representation, respectively, after the requested action.
     1250   For example, if a 204 status is received in response to a PUT
     1251   and the response contains an Etag header field, then the value of
     1252   that field is the current entity-tag for the representation that
     1253   was successfully PUT to the requested resource.
     1254</t>
     1255<t>
     1256   If the client is a user agent, it &SHOULD-NOT; change its document view
    12531257   from that which caused the request to be sent. This response is
    12541258   primarily intended to allow input for actions to take place without
    12551259   causing a change to the user agent's active document view, although
    1256    any new or updated metainformation &SHOULD; be applied to the document
     1260   any new or updated metadata &SHOULD; be applied to the document
    12571261   currently in the user agent's active view.
    12581262</t>
Note: See TracChangeset for help on using the changeset viewer.