Changeset 1921 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 01/10/12 04:39:53 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r1920 r1921 318 318 <t> 319 319 The "Content-Type" header field indicates the media type of the 320 representation. In the case of responses to the HEAD method, the media type is 320 representation, which defines both the data format and how that data 321 &SHOULD; be processed by the recipient (within the scope of the request 322 method semantics). For responses to the HEAD method, the media type is 321 323 that which would have been sent had the request been a GET. 322 324 </t> … … 331 333 </artwork></figure> 332 334 <t> 333 Further discussion of Content-Type is provided in <xref target="representation.data"/>. 335 A sender &SHOULD; include a Content-Type header field in a message 336 containing a payload body, defining the media type of the enclosed 337 representation, unless the intended media type is unknown to the sender. 338 If a Content-Type header field is not present, recipients &MAY; either 339 assume a media type of 340 "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>) 341 or examine the representation data to determine its type. 342 </t> 343 <t> 344 In practice, resource owners do not always properly configure their origin 345 server to provide the correct Content-Type for a given representation, 346 with the result that some clients will examine a payload's content 347 and override the specified type. 348 Clients that do so risk drawing incorrect conclusions, which might expose 349 additional security risks (e.g., "privilege escalation"). Furthermore, 350 it is impossible to determine the sender's intent by examining the data 351 format: many data formats match multiple media types that differ only in 352 processing semantics. Implementers are encouraged to provide a means of 353 disabling such "content sniffing" when it is used. 334 354 </t> 335 355 </section> … … 546 566 representation-data := Content-Encoding( Content-Type( bits ) ) 547 567 </artwork></figure> 548 <t>549 <x:ref>Content-Type</x:ref> specifies the media type of the underlying data,550 which defines both the data format and how that data &SHOULD; be processed551 by the recipient (within the scope of the request method semantics).552 Any HTTP/1.1 message containing a payload body &SHOULD; include a553 Content-Type header field defining the media type of the associated554 representation unless that metadata is unknown to the sender.555 If the Content-Type header field is not present, it indicates that556 the sender does not know the media type of the representation;557 recipients &MAY; either assume that the media type is558 "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)559 or examine the content to determine its type.560 </t>561 <t>562 In practice, resource owners do not always properly configure their origin563 server to provide the correct Content-Type for a given representation,564 with the result that some clients will examine a payload's content565 and override the specified type.566 Clients that do so risk drawing incorrect conclusions, which might expose567 additional security risks (e.g., "privilege escalation"). Furthermore,568 it is impossible to determine the sender's intent by examining the data569 format: many data formats match multiple media types that differ only in570 processing semantics. Implementers are encouraged to provide a means of571 disabling such "content sniffing" when it is used.572 </t>573 <t>574 <x:ref>Content-Encoding</x:ref> is used to indicate any additional content575 codings applied to the data, usually for the purpose of data576 compression, that are a property of the representation. If577 Content-Encoding is not present, then there is no additional578 encoding beyond that defined by the <x:ref>Content-Type</x:ref> header field.579 </t>580 568 </section> 581 569
Note: See TracChangeset
for help on using the changeset viewer.