Changeset 1909 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 22/09/12 05:32:51 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r1907 r1909 305 305 </t> 306 306 307 <section title="Representation Header Fields" anchor="representation.header.fields"> 308 <x:anchor-alias value="representation-header"/> 309 <t> 310 Representation header fields define metadata about the representation data 311 enclosed in the message body or, if no message body is present, about 312 the representation that would have been transferred in a <x:ref>200 (OK)</x:ref> 313 response to a simultaneous GET request with the same effective request URI. 314 </t> 315 <t> 316 The following header fields are defined as representation metadata: 317 </t> 318 <texttable align="left"> 319 <ttcol>Header Field Name</ttcol> 320 <ttcol>Defined in...</ttcol> 321 322 <c>Content-Type</c> <c><xref target="header.content-type"/></c> 323 <c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c> 324 <c>Content-Language</c> <c><xref target="header.content-language"/></c> 325 <c>Content-Location</c> <c><xref target="header.content-location"/></c> 326 <c>Expires</c> <c>&header-expires;</c> 327 </texttable> 328 329 <section title="Content-Type" anchor="header.content-type"> 330 <iref primary="true" item="Content-Type header field" x:for-anchor=""/> 331 <x:anchor-alias value="Content-Type"/> 332 <t> 333 The "Content-Type" header field indicates the media type of the 334 representation. In the case of responses to the HEAD method, the media type is 335 that which would have been sent had the request been a GET. 336 </t> 337 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/> 338 <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref> 339 </artwork></figure> 340 <t> 341 Media types are defined in <xref target="media.types"/>. An example of the field is 342 </t> 343 <figure><artwork type="example"> 344 Content-Type: text/html; charset=ISO-8859-4 345 </artwork></figure> 346 <t> 347 Further discussion of Content-Type is provided in <xref target="representation.data"/>. 348 </t> 349 </section> 350 351 <section title="Content-Encoding" anchor="header.content-encoding"> 352 <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/> 353 <x:anchor-alias value="Content-Encoding"/> 354 <t> 355 The "Content-Encoding" header field indicates what content-codings 356 have been applied to the representation beyond those inherent in the media 357 type, and thus what decoding mechanisms have to be applied in order to obtain 358 the media-type referenced by the <x:ref>Content-Type</x:ref> header field. 359 Content-Encoding is primarily used to allow a representation to be 360 compressed without losing the identity of its underlying media type. 361 </t> 362 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/> 363 <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref> 364 </artwork></figure> 365 <t> 366 Content codings are defined in <xref target="content.codings"/>. An example of its use is 367 </t> 368 <figure><artwork type="example"> 369 Content-Encoding: gzip 370 </artwork></figure> 371 <t> 372 The content-coding is a characteristic of the representation. 373 Typically, the representation body is stored with this 374 encoding and is only decoded before rendering or analogous usage. 375 However, a transforming proxy &MAY; modify the content-coding if the 376 new coding is known to be acceptable to the recipient, unless the 377 "no-transform" cache-control directive is present in the message. 378 </t> 379 <t> 380 If the media type includes an inherent encoding, such as a data format 381 that is always compressed, then that encoding would not be restated as 382 a Content-Encoding even if it happens to be the same algorithm as one 383 of the content-codings. Such a content-coding would only be listed if, 384 for some bizarre reason, it is applied a second time to form the 385 representation. Likewise, an origin server might choose to publish the 386 same payload data as multiple representations that differ only in whether 387 the coding is defined as part of <x:ref>Content-Type</x:ref> or 388 Content-Encoding, since some user agents will behave differently in their 389 handling of each response (e.g., open a "Save as ..." dialog instead of 390 automatic decompression and rendering of content). 391 </t> 392 <t> 393 A representation that has a content-coding applied to it &MUST; include 394 a Content-Encoding header field that lists the content-coding(s) applied. 395 </t> 396 <t> 397 If multiple encodings have been applied to a representation, the content 398 codings &MUST; be listed in the order in which they were applied. 399 Additional information about the encoding parameters &MAY; be provided 400 by other header fields not defined by this specification. 401 </t> 402 <t> 403 If the content-coding of a representation in a request message is not 404 acceptable to the origin server, the server &SHOULD; respond with a 405 status code of 415 (Unsupported Media Type). 406 </t> 407 </section> 408 409 <section title="Content-Language" anchor="header.content-language"> 410 <iref primary="true" item="Content-Language header field" x:for-anchor=""/> 411 <x:anchor-alias value="Content-Language"/> 412 <t> 413 The "Content-Language" header field describes the natural 414 language(s) of the intended audience for the representation. Note that this might 415 not be equivalent to all the languages used within the representation. 416 </t> 417 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/> 418 <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref> 419 </artwork></figure> 420 <t> 421 Language tags are defined in <xref target="language.tags"/>. The primary purpose of 422 Content-Language is to allow a user to identify and differentiate 423 representations according to the user's own preferred language. Thus, if the 424 body content is intended only for a Danish-literate audience, the 425 appropriate field is 426 </t> 427 <figure><artwork type="example"> 428 Content-Language: da 429 </artwork></figure> 430 <t> 431 If no Content-Language is specified, the default is that the content 432 is intended for all language audiences. This might mean that the 433 sender does not consider it to be specific to any natural language, 434 or that the sender does not know for which language it is intended. 435 </t> 436 <t> 437 Multiple languages &MAY; be listed for content that is intended for 438 multiple audiences. For example, a rendition of the "Treaty of 439 Waitangi", presented simultaneously in the original Maori and English 440 versions, would call for 441 </t> 442 <figure><artwork type="example"> 443 Content-Language: mi, en 444 </artwork></figure> 445 <t> 446 However, just because multiple languages are present within a representation 447 does not mean that it is intended for multiple linguistic audiences. 448 An example would be a beginner's language primer, such as "A First 449 Lesson in Latin", which is clearly intended to be used by an 450 English-literate audience. In this case, the Content-Language would 451 properly only include "en". 452 </t> 453 <t> 454 Content-Language &MAY; be applied to any media type — it is not 455 limited to textual documents. 456 </t> 457 </section> 458 459 <section title="Content-Location" anchor="header.content-location"> 460 <iref primary="true" item="Content-Location header field" x:for-anchor=""/> 461 <x:anchor-alias value="Content-Location"/> 462 <t> 463 The "Content-Location" header field supplies a URI that can be used 464 as a specific identifier for the representation in this message. 465 In other words, if one were to perform a GET on this URI at the time 466 of this message's generation, then a <x:ref>200 (OK)</x:ref> response would 467 contain the same representation that is enclosed as payload in this message. 468 </t> 469 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/> 470 <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref> 471 </artwork></figure> 472 <t> 473 The Content-Location value is not a replacement for the effective 474 Request URI (&effective-request-uri;). It is representation metadata. 475 It has the same syntax and semantics as the header field of the same name 476 defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>. 477 However, its appearance in an HTTP message has some special implications 478 for HTTP recipients. 479 </t> 480 <t> 481 If Content-Location is included in a response message and its value 482 is the same as the effective request URI, then the response payload 483 &SHOULD; be considered a current representation of that resource. 484 For a GET or HEAD request, this is the same as the default semantics 485 when no Content-Location is provided by the server. For a state-changing 486 request like PUT or POST, it implies that the server's response contains 487 the new representation of that resource, thereby distinguishing it from 488 representations that might only report about the action (e.g., "It worked!"). 489 This allows authoring applications to update their local copies without 490 the need for a subsequent GET request. 491 </t> 492 <t> 493 If Content-Location is included in a response message and its value 494 differs from the effective request URI, then the origin server is 495 informing recipients that this representation has its own, presumably 496 more specific, identifier. For a GET or HEAD request, this is an 497 indication that the effective request URI identifies a resource that 498 is subject to content negotiation and the selected representation for 499 this response can also be found at the identified URI. For other 500 methods, such a Content-Location indicates that this representation 501 contains a report on the action's status and the same report is 502 available (for future access with GET) at the given URI. For 503 example, a purchase transaction made via a POST request might 504 include a receipt document as the payload of the <x:ref>200 (OK)</x:ref> 505 response; the Content-Location value provides an identifier for retrieving 506 a copy of that same receipt in the future. 507 </t> 508 <t> 509 If Content-Location is included in a request message, then it &MAY; 510 be interpreted by the origin server as an indication of where the 511 user agent originally obtained the content of the enclosed 512 representation (prior to any subsequent modification of the content 513 by that user agent). In other words, the user agent is providing 514 the same representation metadata that it received with the original 515 representation. However, such interpretation &MUST-NOT; be used to 516 alter the semantics of the method requested by the client. For 517 example, if a client makes a PUT request on a negotiated resource 518 and the origin server accepts that PUT (without redirection), then the 519 new set of values for that resource is expected to be consistent with 520 the one representation supplied in that PUT; the Content-Location 521 cannot be used as a form of reverse content selection that 522 identifies only one of the negotiated representations to be updated. 523 If the user agent had wanted the latter semantics, it would have applied 524 the PUT directly to the Content-Location URI. 525 </t> 526 <t> 527 A Content-Location field received in a request message is transitory 528 information that &SHOULD-NOT; be saved with other representation 529 metadata for use in later responses. The Content-Location's value 530 might be saved for use in other contexts, such as within source links 531 or other metadata. 532 </t> 533 <t> 534 A cache cannot assume that a representation with a Content-Location 535 different from the URI used to retrieve it can be used to respond to 536 later requests on that Content-Location URI. 537 </t> 538 <t> 539 If the Content-Location value is a partial URI, the partial URI is 540 interpreted relative to the effective request URI. 541 </t> 542 </section> 543 </section> 544 545 <section title="Selected Representation Header Fields" anchor="selected.representation"> 546 <t><iref primary="true" item="selected representation"/> 547 We use the term "<x:dfn>selected representation</x:dfn>" to refer to the 548 the current representation of a target resource that would have been 549 selected in a successful response if the same request had used the 550 method GET and excluded any conditional request header fields. 551 </t> 552 <t> 553 Additional header fields define metadata about the selected 554 representation, which might differ from the representation included 555 in the message for responses to some state-changing methods. 556 The following header fields are defined as selected representation 557 metadata: 558 </t> 559 <texttable align="left"> 560 <ttcol>Header Field Name</ttcol> 561 <ttcol>Defined in...</ttcol> 562 563 <c>ETag</c> <c>&header-etag;</c> 564 <c>Last-Modified</c> <c>&header-last-modified;</c> 565 </texttable> 566 </section> 567 568 <section title="Representation Data" anchor="representation.data"> 569 <x:anchor-alias value="representation-data"/> 570 <t> 571 The representation body associated with an HTTP message is 572 either provided as the payload body of the message or 573 referred to by the message semantics and the effective request 574 URI. The representation data is in a format and encoding defined by 575 the representation metadata header fields. 576 </t> 577 <t> 578 The data type of the representation data is determined via the header fields 579 <x:ref>Content-Type</x:ref> and <x:ref>Content-Encoding</x:ref>. 580 These define a two-layer, ordered encoding model: 581 </t> 582 <figure><artwork type="example"> 583 representation-data := Content-Encoding( Content-Type( bits ) ) 584 </artwork></figure> 585 <t> 586 <x:ref>Content-Type</x:ref> specifies the media type of the underlying data, 587 which defines both the data format and how that data &SHOULD; be processed 588 by the recipient (within the scope of the request method semantics). 589 Any HTTP/1.1 message containing a payload body &SHOULD; include a 590 Content-Type header field defining the media type of the associated 591 representation unless that metadata is unknown to the sender. 592 If the Content-Type header field is not present, it indicates that 593 the sender does not know the media type of the representation; 594 recipients &MAY; either assume that the media type is 595 "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>) 596 or examine the content to determine its type. 597 </t> 598 <t> 599 In practice, resource owners do not always properly configure their origin 600 server to provide the correct Content-Type for a given representation, 601 with the result that some clients will examine a response body's content 602 and override the specified type. 603 Clients that do so risk drawing incorrect conclusions, which might expose 604 additional security risks (e.g., "privilege escalation"). Furthermore, 605 it is impossible to determine the sender's intent by examining the data 606 format: many data formats match multiple media types that differ only in 607 processing semantics. Implementers are encouraged to provide a means of 608 disabling such "content sniffing" when it is used. 609 </t> 610 <t> 611 <x:ref>Content-Encoding</x:ref> is used to indicate any additional content 612 codings applied to the data, usually for the purpose of data 613 compression, that are a property of the representation. If 614 Content-Encoding is not present, then there is no additional 615 encoding beyond that defined by the <x:ref>Content-Type</x:ref> header field. 616 </t> 617 </section> 618 307 619 <section title="Message Payload" anchor="payload"> 308 620 <iref item="payload"/> … … 407 719 </t> 408 720 </section> 409 </section>410 411 <section title="Representation Header Fields" anchor="representation.header.fields">412 <x:anchor-alias value="representation-header"/>413 <t>414 Representation header fields define metadata about the representation data415 enclosed in the message body or, if no message body is present, about416 the representation that would have been transferred in a <x:ref>200 (OK)</x:ref>417 response to a simultaneous GET request with the same effective request URI.418 </t>419 <t>420 The following header fields are defined as representation metadata:421 </t>422 <texttable align="left">423 <ttcol>Header Field Name</ttcol>424 <ttcol>Defined in...</ttcol>425 426 <c>Content-Type</c> <c><xref target="header.content-type"/></c>427 <c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c>428 <c>Content-Language</c> <c><xref target="header.content-language"/></c>429 <c>Content-Location</c> <c><xref target="header.content-location"/></c>430 <c>Expires</c> <c>&header-expires;</c>431 </texttable>432 433 <section title="Content-Type" anchor="header.content-type">434 <iref primary="true" item="Content-Type header field" x:for-anchor=""/>435 <x:anchor-alias value="Content-Type"/>436 <t>437 The "Content-Type" header field indicates the media type of the438 representation. In the case of responses to the HEAD method, the media type is439 that which would have been sent had the request been a GET.440 </t>441 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>442 <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>443 </artwork></figure>444 <t>445 Media types are defined in <xref target="media.types"/>. An example of the field is446 </t>447 <figure><artwork type="example">448 Content-Type: text/html; charset=ISO-8859-4449 </artwork></figure>450 <t>451 Further discussion of Content-Type is provided in <xref target="representation.data"/>.452 </t>453 </section>454 455 <section title="Content-Encoding" anchor="header.content-encoding">456 <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>457 <x:anchor-alias value="Content-Encoding"/>458 <t>459 The "Content-Encoding" header field indicates what content-codings460 have been applied to the representation beyond those inherent in the media461 type, and thus what decoding mechanisms have to be applied in order to obtain462 the media-type referenced by the <x:ref>Content-Type</x:ref> header field.463 Content-Encoding is primarily used to allow a representation to be464 compressed without losing the identity of its underlying media type.465 </t>466 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>467 <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>468 </artwork></figure>469 <t>470 Content codings are defined in <xref target="content.codings"/>. An example of its use is471 </t>472 <figure><artwork type="example">473 Content-Encoding: gzip474 </artwork></figure>475 <t>476 The content-coding is a characteristic of the representation.477 Typically, the representation body is stored with this478 encoding and is only decoded before rendering or analogous usage.479 However, a transforming proxy &MAY; modify the content-coding if the480 new coding is known to be acceptable to the recipient, unless the481 "no-transform" cache-control directive is present in the message.482 </t>483 <t>484 If the media type includes an inherent encoding, such as a data format485 that is always compressed, then that encoding would not be restated as486 a Content-Encoding even if it happens to be the same algorithm as one487 of the content-codings. Such a content-coding would only be listed if,488 for some bizarre reason, it is applied a second time to form the489 representation. Likewise, an origin server might choose to publish the490 same payload data as multiple representations that differ only in whether491 the coding is defined as part of <x:ref>Content-Type</x:ref> or492 Content-Encoding, since some user agents will behave differently in their493 handling of each response (e.g., open a "Save as ..." dialog instead of494 automatic decompression and rendering of content).495 </t>496 <t>497 A representation that has a content-coding applied to it &MUST; include498 a Content-Encoding header field that lists the content-coding(s) applied.499 </t>500 <t>501 If multiple encodings have been applied to a representation, the content502 codings &MUST; be listed in the order in which they were applied.503 Additional information about the encoding parameters &MAY; be provided504 by other header fields not defined by this specification.505 </t>506 <t>507 If the content-coding of a representation in a request message is not508 acceptable to the origin server, the server &SHOULD; respond with a509 status code of 415 (Unsupported Media Type).510 </t>511 </section>512 513 <section title="Content-Language" anchor="header.content-language">514 <iref primary="true" item="Content-Language header field" x:for-anchor=""/>515 <x:anchor-alias value="Content-Language"/>516 <t>517 The "Content-Language" header field describes the natural518 language(s) of the intended audience for the representation. Note that this might519 not be equivalent to all the languages used within the representation.520 </t>521 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>522 <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>523 </artwork></figure>524 <t>525 Language tags are defined in <xref target="language.tags"/>. The primary purpose of526 Content-Language is to allow a user to identify and differentiate527 representations according to the user's own preferred language. Thus, if the528 body content is intended only for a Danish-literate audience, the529 appropriate field is530 </t>531 <figure><artwork type="example">532 Content-Language: da533 </artwork></figure>534 <t>535 If no Content-Language is specified, the default is that the content536 is intended for all language audiences. This might mean that the537 sender does not consider it to be specific to any natural language,538 or that the sender does not know for which language it is intended.539 </t>540 <t>541 Multiple languages &MAY; be listed for content that is intended for542 multiple audiences. For example, a rendition of the "Treaty of543 Waitangi", presented simultaneously in the original Maori and English544 versions, would call for545 </t>546 <figure><artwork type="example">547 Content-Language: mi, en548 </artwork></figure>549 <t>550 However, just because multiple languages are present within a representation551 does not mean that it is intended for multiple linguistic audiences.552 An example would be a beginner's language primer, such as "A First553 Lesson in Latin", which is clearly intended to be used by an554 English-literate audience. In this case, the Content-Language would555 properly only include "en".556 </t>557 <t>558 Content-Language &MAY; be applied to any media type — it is not559 limited to textual documents.560 </t>561 </section>562 563 <section title="Content-Location" anchor="header.content-location">564 <iref primary="true" item="Content-Location header field" x:for-anchor=""/>565 <x:anchor-alias value="Content-Location"/>566 <t>567 The "Content-Location" header field supplies a URI that can be used568 as a specific identifier for the representation in this message.569 In other words, if one were to perform a GET on this URI at the time570 of this message's generation, then a <x:ref>200 (OK)</x:ref> response would571 contain the same representation that is enclosed as payload in this message.572 </t>573 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>574 <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>575 </artwork></figure>576 <t>577 The Content-Location value is not a replacement for the effective578 Request URI (&effective-request-uri;). It is representation metadata.579 It has the same syntax and semantics as the header field of the same name580 defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.581 However, its appearance in an HTTP message has some special implications582 for HTTP recipients.583 </t>584 <t>585 If Content-Location is included in a response message and its value586 is the same as the effective request URI, then the response payload587 &SHOULD; be considered a current representation of that resource.588 For a GET or HEAD request, this is the same as the default semantics589 when no Content-Location is provided by the server. For a state-changing590 request like PUT or POST, it implies that the server's response contains591 the new representation of that resource, thereby distinguishing it from592 representations that might only report about the action (e.g., "It worked!").593 This allows authoring applications to update their local copies without594 the need for a subsequent GET request.595 </t>596 <t>597 If Content-Location is included in a response message and its value598 differs from the effective request URI, then the origin server is599 informing recipients that this representation has its own, presumably600 more specific, identifier. For a GET or HEAD request, this is an601 indication that the effective request URI identifies a resource that602 is subject to content negotiation and the selected representation for603 this response can also be found at the identified URI. For other604 methods, such a Content-Location indicates that this representation605 contains a report on the action's status and the same report is606 available (for future access with GET) at the given URI. For607 example, a purchase transaction made via a POST request might608 include a receipt document as the payload of the <x:ref>200 (OK)</x:ref>609 response; the Content-Location value provides an identifier for retrieving610 a copy of that same receipt in the future.611 </t>612 <t>613 If Content-Location is included in a request message, then it &MAY;614 be interpreted by the origin server as an indication of where the615 user agent originally obtained the content of the enclosed616 representation (prior to any subsequent modification of the content617 by that user agent). In other words, the user agent is providing618 the same representation metadata that it received with the original619 representation. However, such interpretation &MUST-NOT; be used to620 alter the semantics of the method requested by the client. For621 example, if a client makes a PUT request on a negotiated resource622 and the origin server accepts that PUT (without redirection), then the623 new set of values for that resource is expected to be consistent with624 the one representation supplied in that PUT; the Content-Location625 cannot be used as a form of reverse content selection that626 identifies only one of the negotiated representations to be updated.627 If the user agent had wanted the latter semantics, it would have applied628 the PUT directly to the Content-Location URI.629 </t>630 <t>631 A Content-Location field received in a request message is transitory632 information that &SHOULD-NOT; be saved with other representation633 metadata for use in later responses. The Content-Location's value634 might be saved for use in other contexts, such as within source links635 or other metadata.636 </t>637 <t>638 A cache cannot assume that a representation with a Content-Location639 different from the URI used to retrieve it can be used to respond to640 later requests on that Content-Location URI.641 </t>642 <t>643 If the Content-Location value is a partial URI, the partial URI is644 interpreted relative to the effective request URI.645 </t>646 </section>647 </section>648 649 <section title="Selected Representation Header Fields" anchor="selected.representation">650 <t><iref primary="true" item="selected representation"/>651 We use the term "<x:dfn>selected representation</x:dfn>" to refer to the652 the current representation of a target resource that would have been653 selected in a successful response if the same request had used the654 method GET and excluded any conditional request header fields.655 </t>656 <t>657 Additional header fields define metadata about the selected658 representation, which might differ from the representation included659 in the message for responses to some state-changing methods.660 The following header fields are defined as selected representation661 metadata:662 </t>663 <texttable align="left">664 <ttcol>Header Field Name</ttcol>665 <ttcol>Defined in...</ttcol>666 667 <c>ETag</c> <c>&header-etag;</c>668 <c>Last-Modified</c> <c>&header-last-modified;</c>669 </texttable>670 </section>671 672 <section title="Representation Data" anchor="representation.data">673 <x:anchor-alias value="representation-data"/>674 <t>675 The representation body associated with an HTTP message is676 either provided as the payload body of the message or677 referred to by the message semantics and the effective request678 URI. The representation data is in a format and encoding defined by679 the representation metadata header fields.680 </t>681 <t>682 The data type of the representation data is determined via the header fields683 <x:ref>Content-Type</x:ref> and <x:ref>Content-Encoding</x:ref>.684 These define a two-layer, ordered encoding model:685 </t>686 <figure><artwork type="example">687 representation-data := Content-Encoding( Content-Type( bits ) )688 </artwork></figure>689 <t>690 <x:ref>Content-Type</x:ref> specifies the media type of the underlying data,691 which defines both the data format and how that data &SHOULD; be processed692 by the recipient (within the scope of the request method semantics).693 Any HTTP/1.1 message containing a payload body &SHOULD; include a694 Content-Type header field defining the media type of the associated695 representation unless that metadata is unknown to the sender.696 If the Content-Type header field is not present, it indicates that697 the sender does not know the media type of the representation;698 recipients &MAY; either assume that the media type is699 "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)700 or examine the content to determine its type.701 </t>702 <t>703 In practice, resource owners do not always properly configure their origin704 server to provide the correct Content-Type for a given representation,705 with the result that some clients will examine a response body's content706 and override the specified type.707 Clients that do so risk drawing incorrect conclusions, which might expose708 additional security risks (e.g., "privilege escalation"). Furthermore,709 it is impossible to determine the sender's intent by examining the data710 format: many data formats match multiple media types that differ only in711 processing semantics. Implementers are encouraged to provide a means of712 disabling such "content sniffing" when it is used.713 </t>714 <t>715 <x:ref>Content-Encoding</x:ref> is used to indicate any additional content716 codings applied to the data, usually for the purpose of data717 compression, that are a property of the representation. If718 Content-Encoding is not present, then there is no additional719 encoding beyond that defined by the <x:ref>Content-Type</x:ref> header field.720 </t>721 721 </section> 722 722
Note: See TracChangeset
for help on using the changeset viewer.