Changeset 856 for draft-ietf-httpbis
- Timestamp:
- 19/07/10 11:52:07 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r848 r856 1185 1185 The request has been fulfilled and has resulted in a new resource being 1186 1186 created. The newly created resource can be referenced by the URI(s) 1187 returned in the entityof the response, with the most specific URI1187 returned in the payload of the response, with the most specific URI 1188 1188 for the resource given by a Location header field. The response 1189 &SHOULD; include a n entitycontaining a list of resource1189 &SHOULD; include a payload containing a list of resource 1190 1190 characteristics and location(s) from which the user or user agent can 1191 choose the one most appropriate. The entityformat is specified by1191 choose the one most appropriate. The payload format is specified by 1192 1192 the media type given in the Content-Type header field. The origin 1193 1193 server &MUST; create the resource before returning the 201 status code. … … 1197 1197 <t> 1198 1198 A 201 response &MAY; contain an ETag response header field indicating 1199 the current value of the entity tag for the re quested variant just1200 created, see &header-etag;.1199 the current value of the entity tag for the representation of the resource 1200 just created (see &header-etag;). 1201 1201 </t> 1202 1202 </section> … … 1243 1243 <iref primary="true" item="Status Codes" subitem="204 No Content" x:for-anchor=""/> 1244 1244 <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 1253 1257 from that which caused the request to be sent. This response is 1254 1258 primarily intended to allow input for actions to take place without 1255 1259 causing a change to the user agent's active document view, although 1256 any new or updated meta information&SHOULD; be applied to the document1260 any new or updated metadata &SHOULD; be applied to the document 1257 1261 currently in the user agent's active view. 1258 1262 </t> -
draft-ietf-httpbis/latest/p3-payload.xml
r854 r856 256 256 <t> 257 257 The mechanism for selecting the appropriate representation when 258 servicing a request. The representation of entitiesin any response258 servicing a request. The representation in any response 259 259 can be negotiated (including error responses). 260 260 </t> … … 262 262 </t> 263 263 <t> 264 <iref item=" entity"/>265 <x:dfn> entity</x:dfn>264 <iref item="payload"/> 265 <x:dfn>payload</x:dfn> 266 266 <list> 267 267 <t> 268 The information transferred as the payload of a request or 269 response. An entity consists of metadata in the form of 270 entity-header fields and content in the form of an entity-body. 268 The information transferred within a given message is called the 269 payload, consisting of optional payload metadata and an optional 270 payload body. The payload in HTTP is always a partial or complete 271 representation of some resource, though which resource is represented 272 is dependent on the type of message (request or response), the 273 request method, and the response status code. 271 274 </t> 272 275 </list> … … 277 280 <list> 278 281 <t> 279 An entity included with a response that is subject to content 280 negotiation. There may exist multiple 281 representations associated with a particular response status. 282 </t> 283 </list> 284 </t> 285 <t> 286 <iref item="variant"/> 287 <x:dfn>variant</x:dfn> 288 <list> 289 <t> 290 A resource may have one, or more than one, representation(s) 291 associated with it at any given instant. Each of these 292 representations is termed a "variant". Use of the term "variant" 293 does not necessarily imply that the resource is subject to content 294 negotiation. 282 A representation is information in a format that can be readily 283 communicated from one party to another. For our purposes, a 284 representation is binary data and its associated metadata. 285 A representation of a resource is information that reflects the 286 state of that resource, as observed at some point in the past 287 or to be desired at some point in the future. 295 288 </t> 296 289 </list> … … 1420 1413 <x:anchor-alias value="Content-Location-v"/> 1421 1414 <t> 1422 The "Content-Location" entity-header field is used to supply a URI for the 1423 entity in the message when it is accessible from a location separate from 1424 the requested resource's URI. 1425 </t> 1426 <t> 1427 A server &SHOULD; provide a Content-Location for the variant corresponding 1428 to the response entity, especially in the case where a resource has multiple 1429 entities associated with it, and those entities actually have separate 1430 locations by which they might be individually accessed, the server &SHOULD; 1431 provide a Content-Location for the particular variant which is returned. 1415 The "Content-Location" header field supplies a URI that can be used 1416 as a specific identifier for the representation in this message. 1417 In other words, if one were to perform a GET on this URI at the time 1418 of this message's generation, then a 200 response would contain the 1419 same representation that is enclosed as payload in this message. 1432 1420 </t> 1433 1421 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/><iref primary="true" item="Grammar" subitem="Content-Location-v"/> … … 1439 1427 <t> 1440 1428 The Content-Location value is not a replacement for the Effective 1441 Request URI (&effective-request-uri;); it is only a statement of the location of the resource 1442 corresponding to this particular entity at the time of the request. 1443 Future requests &MAY; may be addressed to the Content-Location URI 1444 if the desire is to identify the source of that particular 1445 entity. 1446 </t> 1447 <t> 1448 &response-representation; describes how clients may process the Content-Location header field. 1449 </t> 1450 <t> 1451 A cache cannot assume that an entity with a Content-Location 1429 Request URI (&effective-request-uri;). It is representation metadata. 1430 It has the same syntax and semantics as the header field of the same name 1431 defined for MIME body parts in <xref target="RFC2557" x:sec="4"/>. 1432 However, its appearance in an HTTP message has some special implications 1433 for HTTP recipients. 1434 </t> 1435 <t> 1436 If Content-Location is included in a response message and its value 1437 is the same as the Effective Request URI, then the response payload 1438 &SHOULD; be considered the current representation of that resource. 1439 For a GET or HEAD request, this is the same as the default semantics 1440 when no Content-Location is provided by the server. For a state-changing 1441 method like PUT or POST, it implies that the server's response contains 1442 the new representation of that resource, thereby distinguishing it from 1443 representations that might only report about the action (e.g., "It worked!"). 1444 This allows authoring applications to update their local copies without 1445 the need for a subsequent GET request. 1446 </t> 1447 <t> 1448 If Content-Location is included in a response message and its value 1449 differs from the Effective Request URI, then the origin server is 1450 informing recipients that this representation has its own, presumably 1451 more specific, identifier. For a GET or HEAD request, this is an 1452 indication that the Effective Request URI identifies a resource that 1453 is subject to content negotiation and the representation selected for 1454 this response can also be found at the identified URI. For other 1455 methods, such a Content-Location indicates that this representation 1456 contains a report on the action's status and the same report is 1457 available (for future access with GET) at the given URI. For 1458 example, a purchase transaction made via the POST method may 1459 include a receipt document as the payload of the 200 response; 1460 the Content-Location value provides an identifier for retrieving 1461 a copy of that same receipt in the future. 1462 </t> 1463 <t> 1464 If Content-Location is included in a request message, then it &MAY; 1465 be interpreted by the origin server as an indication of where the 1466 user agent originally obtained the content of the enclosed 1467 representation (prior to any subsequent modification of the content 1468 by that user agent). In other words, the user agent is providing 1469 the same representation metadata that it received with the original 1470 representation. However, such interpretation &MUST-NOT; be used to 1471 alter the semantics of the method requested by the client. For 1472 example, if a client makes a PUT request on a negotiated resource 1473 and the origin server accepts that PUT (without redirection), then the 1474 new set of values for that resource is expected to be consistent with 1475 the one representation supplied in that PUT; the Content-Location 1476 cannot be used as a form of reverse content selection that 1477 identifies only one of the negotiated representations to be updated. 1478 If the user agent had wanted the latter semantics, it would have applied 1479 the PUT directly to the Content-Location URI. 1480 </t> 1481 <t> 1482 A Content-Location field received in a request message is transitory 1483 information that &SHOULD-NOT; be saved with other representation 1484 metadata for use in later responses. The Content-Location's value 1485 might be saved for use in other contexts, such as within source links 1486 or other metadata. 1487 </t> 1488 <t> 1489 A cache cannot assume that a representation with a Content-Location 1452 1490 different from the URI used to retrieve it can be used to respond to 1453 later requests on that Content-Location URI. However, the Content-Location 1454 can be used to differentiate between multiple entities 1455 retrieved from a single requested resource, as described in &caching-neg-resp;. 1456 </t> 1457 <t> 1458 If the Content-Location is a relative URI, the relative URI is 1491 later requests on that Content-Location URI. 1492 </t> 1493 <t> 1494 If the Content-Location value is a partial URI, it is 1459 1495 interpreted relative to the Effective Request URI. 1460 </t>1461 <t>1462 The meaning of the Content-Location header in requests is1463 undefined; servers are free to ignore it in those cases.1464 1496 </t> 1465 1497 </section>
Note: See TracChangeset
for help on using the changeset viewer.