Changeset 856 for draft-ietf-httpbis/latest/p3-payload.xml
- Timestamp:
- 19/07/10 11:52:07 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
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.