![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 875 for draft-ietf-httpbis/latest/p3-payload.html
- Timestamp:
- Jul 22, 2010, 10:43:59 PM (9 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p3-payload.html (modified) (41 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p3-payload.html
r868 r875 377 377 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 378 378 <link rel="Chapter" title="2 Protocol Parameters" href="#rfc.section.2"> 379 <link rel="Chapter" title="3 Entity" href="#rfc.section.3">379 <link rel="Chapter" title="3 Representation" href="#rfc.section.3"> 380 380 <link rel="Chapter" title="4 Content Negotiation" href="#rfc.section.4"> 381 381 <link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5"> … … 384 384 <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8"> 385 385 <link rel="Chapter" href="#rfc.section.9" title="9 References"> 386 <link rel="Appendix" title="A Differences Between HTTP Entities and RFC 2045 Entities" href="#rfc.section.A">386 <link rel="Appendix" title="A Differences between HTTP and MIME" href="#rfc.section.A"> 387 387 <link rel="Appendix" title="B Additional Features" href="#rfc.section.B"> 388 388 <link rel="Appendix" title="C Compatibility with Previous Versions" href="#rfc.section.C"> … … 555 555 </ul> 556 556 </li> 557 <li class="tocline0">3. <a href="# entity">Entity</a><ul class="toc">557 <li class="tocline0">3. <a href="#representation">Representation</a><ul class="toc"> 558 558 <li class="tocline1">3.1 <a href="#entity.header.fields">Entity Header Fields</a></li> 559 <li class="tocline1">3.2 <a href="# entity.body">EntityBody</a><ul class="toc">559 <li class="tocline1">3.2 <a href="#payload.body">Payload Body</a><ul class="toc"> 560 560 <li class="tocline1">3.2.1 <a href="#type">Type</a></li> 561 561 </ul> … … 597 597 </li> 598 598 <li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li> 599 <li class="tocline0">A. <a href="#differences.between.http. entities.and.rfc.2045.entities">Differences Between HTTP Entities and RFC 2045 Entities</a><ul class="toc">599 <li class="tocline0">A. <a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul class="toc"> 600 600 <li class="tocline1">A.1 <a href="#mime-version">MIME-Version</a></li> 601 601 <li class="tocline1">A.2 <a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li> … … 818 818 </p> 819 819 <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a> <a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h3> 820 <p id="rfc.section.2.3.1.p.1">Internet media types are registered with a canonical form. An entity-body transferred via HTTP messages <em class="bcp14">MUST</em> be represented in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next 821 paragraph. 820 <p id="rfc.section.2.3.1.p.1">Internet media types are registered with a canonical form. A representation transferred via HTTP messages <em class="bcp14">MUST</em> be in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph. 822 821 </p> 823 822 <p id="rfc.section.2.3.1.p.2">When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and 824 823 allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an 825 entire entity-body. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP. In addition, if826 the text is represented in a character set that does not use octets 13 and 10 for CR and LF respectively, as is the case for827 some multi-byte character sets, HTTP allows the use of whatever octet sequences are defined by that character set to represent828 the equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the entity-body;829 a bare CR or LF <em class="bcp14">MUST NOT</em> be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).830 </p> 831 <p id="rfc.section.2.3.1.p.3">If a n entity-bodyis encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded.832 </p> 833 <p id="rfc.section.2.3.1.p.4">The "charset" parameter is used with some media types to define the character set(<a href="#character.sets" title="Character Sets">Section 2.1</a>) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined834 to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or835 its subsets <em class="bcp14">MUST</em> be labeled with an appropriate charset value. See <a href="#missing.charset" title="Missing Charset">Section 2.1.1</a> for compatibility problems.824 entire representation. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as indicating a line break in text media received via HTTP. In addition, if the text is 825 in a character encoding that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte 826 character encodings, HTTP allows the use of whatever octet sequences are defined by that character encoding to represent the 827 equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the payload 828 body; a bare CR or LF <em class="bcp14">MUST NOT</em> be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries). 829 </p> 830 <p id="rfc.section.2.3.1.p.3">If a representation is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded. 831 </p> 832 <p id="rfc.section.2.3.1.p.4">The "charset" parameter is used with some media types to define the character encoding (<a href="#character.sets" title="Character Sets">Section 2.1</a>) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined 833 to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character encodings other than "ISO-8859-1" 834 or its subsets <em class="bcp14">MUST</em> be labeled with an appropriate charset value. See <a href="#missing.charset" title="Missing Charset">Section 2.1.1</a> for compatibility problems. 836 835 </p> 837 836 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="multipart.types" href="#multipart.types">Multipart Types</a></h3> 838 <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more entities within a single message-body. All839 multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts.837 <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message-body. 838 All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts. 840 839 </p> 841 840 <p id="rfc.section.2.3.2.p.2">In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. HTTP does … … 866 865 </pre> <p id="rfc.section.2.4.p.6">See <a href="#RFC5646" id="rfc.xref.RFC5646.3"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a> for further information. 867 866 </p> 868 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id=" entity" href="#entity">Entity</a></h1>867 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="representation" href="#representation">Representation</a></h1> 869 868 <p id="rfc.section.3.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists 870 869 of entity-header fields and a representation body, although some responses will only include the entity-headers. … … 874 873 </p> 875 874 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="entity.header.fields" href="#entity.header.fields">Entity Header Fields</a></h2> 876 <p id="rfc.section.3.1.p.1">Entity-header fields define metadata about the entity-body or, if no body is present, about the resource identified by the 877 request. 875 <p id="rfc.section.3.1.p.1">Entity-header fields define metadata about the representation data enclosed in the message-body or, if no message-body is 876 present, about the representation that would have been transferred in a 200 response to a simultaneous GET request on the 877 Effective Request URI. 878 878 </p> 879 879 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span> <a href="#entity.header.fields" class="smpl">entity-header</a> = <a href="#header.content-encoding" class="smpl">Content-Encoding</a> ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section 5.5</a> … … 892 892 fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by the recipient and <em class="bcp14">MUST</em> be forwarded by transparent proxies. 893 893 </p> 894 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="entity.body" href="#entity.body">Entity Body</a></h2> 895 <p id="rfc.section.3.2.p.1">The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p> 896 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.13"></span> <a href="#entity.body" class="smpl">entity-body</a> = *<a href="#notation" class="smpl">OCTET</a> 897 </pre><p id="rfc.section.3.2.p.3">An entity-body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure 894 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="payload.body" href="#payload.body">Payload Body</a></h2> 895 <p id="rfc.section.3.2.p.1">The payload body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p> 896 <p id="rfc.section.3.2.p.2">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure 898 897 safe and proper transfer of the message. 899 898 </p> 900 899 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="type" href="#type">Type</a></h3> 901 <p id="rfc.section.3.2.1.p.1">When a n entity-body is included with a message, the data type of that body is determined via the header fields Content-Type900 <p id="rfc.section.3.2.1.p.1">When a payload body is included with a message, the data type of that body is determined via the header fields Content-Type 902 901 and Content-Encoding. These define a two-layer, ordered encoding model: 903 902 </p> 904 <div id="rfc.figure.u.1 4"></div><pre class="text"> entity-body := Content-Encoding( Content-Type( data ) )905 </pre><p id="rfc.section.3.2.1.p.3">Content-Type specifies the media type of the underlying data. Any HTTP/1.1 message containing a n entity-body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of that body, unless that information is unknown.903 <div id="rfc.figure.u.13"></div><pre class="text"> payload-body := Content-Encoding( Content-Type( data ) ) 904 </pre><p id="rfc.section.3.2.1.p.3">Content-Type specifies the media type of the underlying data. Any HTTP/1.1 message containing a payload body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of that body, unless that information is unknown. 906 905 </p> 907 906 <p id="rfc.section.3.2.1.p.4">If the Content-Type header field is not present, it indicates that the sender does not know the media type of the data; recipients <em class="bcp14">MAY</em> either assume that it is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the content to determine its type. … … 911 910 the specified type. 912 911 </p> 913 <p id="rfc.section.3.2.1.p.6">Client that do so risk drawing incorrect conclusions, which may expose additional security risks (e.g., "privilege escalation").912 <p id="rfc.section.3.2.1.p.6">Clients that do so risk drawing incorrect conclusions, which may expose additional security risks (e.g., "privilege escalation"). 914 913 Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used. 915 914 </p> 916 915 <p id="rfc.section.3.2.1.p.7">Content-Encoding may be used to indicate any additional content codings applied to the data, usually for the purpose of data 917 compression, that are a property of the re quested resource. There is no default encoding.916 compression, that are a property of the representation. There is no default encoding. 918 917 </p> 919 918 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1> … … 977 976 <p id="rfc.section.4.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving 978 977 an initial response from the origin server. Selection is based on a list of the available representations of the response 979 included within the header fields or entity-body of the initial response, with each representation identified by its own URI.980 Selection from among the representations may be performed automatically (if the user agent is capable of doing so) or manually981 by theuser selecting from a generated (possibly hypertext) menu.978 included within the header fields or body of the initial response, with each representation identified by its own URI. Selection 979 from among the representations may be performed automatically (if the user agent is capable of doing so) or manually by the 980 user selecting from a generated (possibly hypertext) menu. 982 981 </p> 983 982 <p id="rfc.section.4.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, … … 1005 1004 for an in-line image. 1006 1005 </p> 1007 <div id="rfc.figure.u.1 5"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span> <a href="#header.accept" class="smpl">Accept</a> = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>1006 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span> <a href="#header.accept" class="smpl">Accept</a> = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a> 1008 1007 <a href="#header.accept" class="smpl">Accept-v</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] ) 1009 1008 … … 1030 1029 </div> 1031 1030 <p id="rfc.section.5.1.p.6">The example</p> 1032 <div id="rfc.figure.u.1 6"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic1031 <div id="rfc.figure.u.15"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 1033 1032 </pre><p id="rfc.section.5.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in 1034 1033 quality." … … 1039 1038 </p> 1040 1039 <p id="rfc.section.5.1.p.10">A more elaborate example is</p> 1041 <div id="rfc.figure.u.1 7"></div><pre class="text"> Accept: text/plain; q=0.5, text/html,1040 <div id="rfc.figure.u.16"></div><pre class="text"> Accept: text/plain; q=0.5, text/html, 1042 1041 text/x-dvi; q=0.8, text/x-c 1043 1042 </pre><p id="rfc.section.5.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then … … 1047 1046 to a given type, the most specific reference has precedence. For example, 1048 1047 </p> 1049 <div id="rfc.figure.u.1 8"></div><pre class="text"> Accept: text/*, text/html, text/html;level=1, */*1048 <div id="rfc.figure.u.17"></div><pre class="text"> Accept: text/*, text/html, text/html;level=1, */* 1050 1049 </pre><p id="rfc.section.5.1.p.15">have the following precedence: </p> 1051 1050 <ol> … … 1058 1057 which matches that type. For example, 1059 1058 </p> 1060 <div id="rfc.figure.u.1 9"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,1059 <div id="rfc.figure.u.18"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 1061 1060 text/html;level=2;q=0.4, */*;q=0.5 1062 1061 </pre><p id="rfc.section.5.1.p.18">would cause the following values to be associated:</p> … … 1107 1106 to a server which is capable of representing documents in those character sets. 1108 1107 </p> 1109 <div id="rfc.figure.u. 20"></div><pre class="inline"><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a>1108 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a> 1110 1109 <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> 1111 1110 <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" ) … … 1114 1113 example is 1115 1114 </p> 1116 <div id="rfc.figure.u.2 1"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.81115 <div id="rfc.figure.u.20"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 1117 1116 </pre><p id="rfc.section.5.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is 1118 1117 not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets … … 1128 1127 <p id="rfc.section.5.3.p.1">The "Accept-Encoding" request-header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section 2.2</a>) are acceptable in the response. 1129 1128 </p> 1130 <div id="rfc.figure.u.2 2"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>1129 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> 1131 1130 <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a> 1132 1131 <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a> = … … 1136 1135 </p> 1137 1136 <p id="rfc.section.5.3.p.4">Examples of its use are:</p> 1138 <div id="rfc.figure.u.2 3"></div><pre class="text"> Accept-Encoding: compress, gzip1137 <div id="rfc.figure.u.22"></div><pre class="text"> Accept-Encoding: compress, gzip 1139 1138 Accept-Encoding: 1140 1139 Accept-Encoding: * … … 1180 1179 in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.4</a>. 1181 1180 </p> 1182 <div id="rfc.figure.u.2 4"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a>1181 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a> 1183 1182 <a href="#header.accept-language" class="smpl">Accept-Language-v</a> 1184 1183 <a href="#header.accept-language" class="smpl">Accept-Language-v</a> = … … 1189 1188 languages specified by that range. The quality value defaults to "q=1". For example, 1190 1189 </p> 1191 <div id="rfc.figure.u.2 5"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.71190 <div id="rfc.figure.u.24"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 1192 1191 </pre><p id="rfc.section.5.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English." (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>) 1193 1192 </p> … … 1218 1217 is primarily used to allow a representation to be compressed without losing the identity of its underlying media type. 1219 1218 </p> 1220 <div id="rfc.figure.u.2 6"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a>1219 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a> 1221 1220 <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a> = 1#<a href="#content.codings" class="smpl">content-coding</a> 1222 1221 </pre><p id="rfc.section.5.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 2.2</a>. An example of its use is 1223 1222 </p> 1224 <div id="rfc.figure.u.2 7"></div><pre class="text"> Content-Encoding: gzip1223 <div id="rfc.figure.u.26"></div><pre class="text"> Content-Encoding: gzip 1225 1224 </pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding 1226 1225 and is only decoded before rendering or analogous usage. However, a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control … … 1229 1228 <p id="rfc.section.5.5.p.6">If the content-coding of a representation is not "identity", then the representation metadata <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section 5.5</a>) that lists the non-identity content-coding(s) used. 1230 1229 </p> 1231 <p id="rfc.section.5.5.p.7">If the content-coding of a n entityin a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).1230 <p id="rfc.section.5.5.p.7">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type). 1232 1231 </p> 1233 1232 <p id="rfc.section.5.5.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. … … 1237 1236 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h2> 1238 1237 <p id="rfc.section.5.6.p.1">The "Content-Language" entity-header field describes the natural language(s) of the intended audience for the representation. 1239 Note that this might not be equivalent to all the languages used within the entity-body.1240 </p> 1241 <div id="rfc.figure.u.2 8"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> <a href="#header.content-language" class="smpl">Content-Language</a> = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a>1238 Note that this might not be equivalent to all the languages used within the representation. 1239 </p> 1240 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span> <a href="#header.content-language" class="smpl">Content-Language</a> = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a> 1242 1241 <a href="#header.content-language" class="smpl">Content-Language-v</a> = 1#<a href="#language.tags" class="smpl">language-tag</a> 1243 1242 </pre><p id="rfc.section.5.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the … … 1245 1244 field is 1246 1245 </p> 1247 <div id="rfc.figure.u.2 9"></div><pre class="text"> Content-Language: da1246 <div id="rfc.figure.u.28"></div><pre class="text"> Content-Language: da 1248 1247 </pre><p id="rfc.section.5.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean 1249 1248 that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language … … 1253 1252 simultaneously in the original Maori and English versions, would call for 1254 1253 </p> 1255 <div id="rfc.figure.u. 30"></div><pre class="text"> Content-Language: mi, en1254 <div id="rfc.figure.u.29"></div><pre class="text"> Content-Language: mi, en 1256 1255 </pre><p id="rfc.section.5.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple 1257 1256 linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly … … 1267 1266 would contain the same representation that is enclosed as payload in this message. 1268 1267 </p> 1269 <div id="rfc.figure.u.3 1"></div><pre class="inline"><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a>1268 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a> 1270 1269 <a href="#header.content-location" class="smpl">Content-Location-v</a> 1271 1270 <a href="#header.content-location" class="smpl">Content-Location-v</a> = … … 1308 1307 <div id="rfc.iref.h.8"></div> 1309 1308 <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a> <a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2> 1310 <p id="rfc.section.5.8.p.1">The "Content-MD5" entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the entity-body that provides an end-to-end message integrity check (MIC) of the entity-body. Note that 1311 a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks. 1312 </p> 1313 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span> <a href="#header.content-md5" class="smpl">Content-MD5</a> = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a> 1309 <p id="rfc.section.5.8.p.1">The "Content-MD5" entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the payload body that provides an end-to-end message integrity check (MIC) of the payload body (the 1310 message-body after any transfer-coding is decoded). Note that a MIC is good for detecting accidental modification of the payload 1311 body in transit, but is not proof against malicious attacks. 1312 </p> 1313 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span> <a href="#header.content-md5" class="smpl">Content-MD5</a> = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a> 1314 1314 <a href="#header.content-md5" class="smpl">Content-MD5-v</a> = <base64 of 128 bit MD5 digest as per <a href="#RFC1864" id="rfc.xref.RFC1864.2"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>> 1315 </pre><p id="rfc.section.5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the entity-body. Only origin servers or clients <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient of the entity-body, including 1316 gateways and proxies, <em class="bcp14">MAY</em> check that the digest value in this header field matches that of the entity-body as received. 1317 </p> 1318 <p id="rfc.section.5.8.p.4">The MD5 digest is computed based on the content of the entity-body, including any content-coding that has been applied, but 1319 not including any transfer-encoding applied to the message-body. If the message is received with a transfer-encoding, that 1320 encoding <em class="bcp14">MUST</em> be removed prior to checking the Content-MD5 value against the received representation. 1321 </p> 1322 <p id="rfc.section.5.8.p.5">This has the result that the digest is computed on the octets of the entity-body exactly as, and in the order that, they would 1323 be sent if no transfer-encoding were being applied. 1324 </p> 1325 <p id="rfc.section.5.8.p.6">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822), 1315 </pre><p id="rfc.section.5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the payload body. Only origin servers or user 1316 agents <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient <em class="bcp14">MAY</em> check that the digest value in this header field matches a corresponding digest calculated on payload body as received. 1317 </p> 1318 <p id="rfc.section.5.8.p.4">The MD5 digest is computed based on the content of the payload body, including any content-coding, but not including any transfer-coding 1319 applied to the message-body because such transfer-codings might be applied or removed anywhere along the request/response 1320 chain. If the message is received with a transfer-coding, that encoding <em class="bcp14">MUST</em> be decoded prior to checking the Content-MD5 value against the received payload. 1321 </p> 1322 <p id="rfc.section.5.8.p.5">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822), 1326 1323 but this does not change how the digest is computed as defined in the preceding paragraph. 1327 1324 </p> 1328 <p id="rfc.section.5.8.p. 7">There are several consequences of this. The entity-bodyfor composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding1325 <p id="rfc.section.5.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding 1329 1326 headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the 1330 1327 body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest as is -- i.e., after the application. 1331 1328 The Transfer-Encoding header field is not allowed within body-parts. 1332 1329 </p> 1333 <p id="rfc.section.5.8.p. 8">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.1334 </p> 1335 <div class="note" id="rfc.section.5.8.p. 9">1330 <p id="rfc.section.5.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest. 1331 </p> 1332 <div class="note" id="rfc.section.5.8.p.8"> 1336 1333 <p> <b>Note:</b> While the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several 1337 1334 ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One … … 1345 1342 <div id="rfc.iref.h.9"></div> 1346 1343 <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h2> 1347 <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the entity-body. In the case of responses to the HEAD method,1348 the media type is that which would have been sent had the request been a GET.1349 </p> 1350 <div id="rfc.figure.u.3 3"></div><pre class="inline"><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a>1344 <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the representation. In the case of responses to the HEAD 1345 method, the media type is that which would have been sent had the request been a GET. 1346 </p> 1347 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a> 1351 1348 <a href="#header.content-type" class="smpl">Content-Type-v</a> = <a href="#media.types" class="smpl">media-type</a> 1352 1349 </pre><p id="rfc.section.5.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 2.3</a>. An example of the field is 1353 1350 </p> 1354 <div id="rfc.figure.u.3 4"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-41355 </pre><p id="rfc.section.5.9.p.5">Further discussion of methods for identifying the media type of a n entityis provided in <a href="#type" title="Type">Section 3.2.1</a>.1351 <div id="rfc.figure.u.33"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 1352 </pre><p id="rfc.section.5.9.p.5">Further discussion of methods for identifying the media type of a representation is provided in <a href="#type" title="Type">Section 3.2.1</a>. 1356 1353 </p> 1357 1354 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> … … 1715 1712 <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span> <span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">Email: <a href="mailto:julian.reschke@greenbytes.de"><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address> 1716 1713 </div> 1717 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="differences.between.http. entities.and.rfc.2045.entities" href="#differences.between.http.entities.and.rfc.2045.entities">Differences Between HTTP Entities and RFC 2045 Entities</a></h1>1718 <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, RFC 20451719 discusses mail, and HTTP has a few features that are different from those described in RFC 2045. These differences were carefully1720 c hosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, to make date1721 comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.1722 </p> 1723 <p id="rfc.section.A.p.2">This appendix describes specific areas where HTTP differs from RFC 2045. Proxies and gateways to strict MIME environments <em class="bcp14">SHOULD</em> be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments1714 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="differences.between.http.and.mime" href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h1> 1715 <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message-body to be transmitted in an open variety of representations and with extensible mechanisms. However, 1716 RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were 1717 carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, 1718 to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients. 1719 </p> 1720 <p id="rfc.section.A.p.2">This appendix describes specific areas where HTTP differs from MIME. Proxies and gateways to strict MIME environments <em class="bcp14">SHOULD</em> be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments 1724 1721 to HTTP also need to be aware of the differences because some conversions might be required. 1725 1722 </p> … … 1732 1729 environments. 1733 1730 </p> 1734 <div id="rfc.figure.u.3 5"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span> <a href="#mime-version" class="smpl">MIME-Version</a> = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a>1731 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span> <a href="#mime-version" class="smpl">MIME-Version</a> = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a> 1735 1732 <a href="#mime-version" class="smpl">MIME-Version-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a> 1736 1733 </pre><p id="rfc.section.A.1.p.3">MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 message parsing and semantics are defined by this … … 1738 1735 </p> 1739 1736 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="conversion.to.canonical.form" href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h2> 1740 <p id="rfc.section.A.2.p.1"> <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> requires that an Internet mail entitybe converted to canonical form prior to being transferred, as described in <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 2.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.4"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line1737 <p id="rfc.section.A.2.p.1">MIME requires that an Internet mail body-part be converted to canonical form prior to being transferred, as described in <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 2.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.4"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line 1741 1738 break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted 1742 1739 over HTTP. … … 1754 1751 </p> 1755 1752 <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a> <a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2> 1756 <p id="rfc.section.A.4.p.1"> RFC 2045 does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier1757 on the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the entity-body before forwarding the message. (Some experimental1758 applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" to perform1759 a function equivalent to Content-Encoding. However, this parameter is not part of RFC 2045).1753 <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on 1754 the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the representation before forwarding the message. (Some 1755 experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" 1756 to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards). 1760 1757 </p> 1761 1758 <h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a> <a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h2> 1762 <p id="rfc.section.A.5.p.1">HTTP does not use the Content-Transfer-Encoding field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.1759 <p id="rfc.section.A.5.p.1">HTTP does not use the Content-Transfer-Encoding field of MIME. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client. 1763 1760 </p> 1764 1761 <p id="rfc.section.A.5.p.2">Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct … … 1790 1787 in <a href="#RFC2183" id="rfc.xref.RFC2183.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>. 1791 1788 </p> 1792 <div id="rfc.figure.u.3 6"></div><pre class="inline"><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span> <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a>1789 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span> <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a> 1793 1790 <a href="#content-disposition" class="smpl">content-disposition-v</a> 1794 1791 <a href="#content-disposition" class="smpl">content-disposition-v</a> = <a href="#content-disposition" class="smpl">disposition-type</a> … … 1800 1797 <a href="#content-disposition" class="smpl">disp-extension-parm</a> = <a href="#core.rules" class="smpl">token</a> "=" <a href="#core.rules" class="smpl">word</a> 1801 1798 </pre><p id="rfc.section.B.1.p.3">An example is</p> 1802 <div id="rfc.figure.u.3 7"></div><pre class="text"> Content-Disposition: attachment; filename="fname.ext"1799 <div id="rfc.figure.u.36"></div><pre class="text"> Content-Disposition: attachment; filename="fname.ext" 1803 1800 </pre><p id="rfc.section.B.1.p.5">The receiving user agent <em class="bcp14">SHOULD NOT</em> respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply 1804 1801 to HTTP implementations at this time. The filename <em class="bcp14">SHOULD</em> be treated as a terminal component only. … … 1830 1827 </p> 1831 1828 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1832 <div id="rfc.figure.u.3 8"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v1829 <div id="rfc.figure.u.37"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v 1833 1830 <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset:" OWS Accept-Charset-v 1834 1831 <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" … … 1887 1884 <a href="#content-disposition" class="smpl">disposition-type</a> = "attachment" / disp-extension-token 1888 1885 1889 <a href="#entity.body" class="smpl">entity-body</a> = *OCTET1890 1886 <a href="#entity.header.fields" class="smpl">entity-header</a> = Content-Encoding / Content-Language / Content-Length 1891 1887 / Content-Location / Content-MD5 / Content-Range / Content-Type / … … 1918 1914 1919 1915 <a href="#core.rules" class="smpl">word</a> = <word, defined in [Part1], Section 1.2.2> 1920 </pre> <div id="rfc.figure.u.3 9"></div>1916 </pre> <div id="rfc.figure.u.38"></div> 1921 1917 <p>ABNF diagnostics:</p><pre class="inline">; Accept defined but not used 1922 1918 ; Accept-Charset defined but not used … … 1925 1921 ; MIME-Version defined but not used 1926 1922 ; content-disposition defined but not used 1927 ; entity-body defined but not used1928 1923 ; entity-header defined but not used 1929 1924 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a> <a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1> … … 2140 2135 <li class="indline1"><tt>Grammar</tt> 2141 2136 <ul class="ind"> 2142 <li class="indline1"><tt>Accept</tt> <a class="iref" href="#rfc.iref.g.1 4"><b>5.1</b></a></li>2143 <li class="indline1"><tt>Accept-Charset</tt> <a class="iref" href="#rfc.iref.g.1 9"><b>5.2</b></a></li>2144 <li class="indline1"><tt>Accept-Charset-v</tt> <a class="iref" href="#rfc.iref.g. 20"><b>5.2</b></a></li>2145 <li class="indline1"><tt>Accept-Encoding</tt> <a class="iref" href="#rfc.iref.g.2 1"><b>5.3</b></a></li>2146 <li class="indline1"><tt>Accept-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.2 2"><b>5.3</b></a></li>2147 <li class="indline1"><tt>accept-ext</tt> <a class="iref" href="#rfc.iref.g.1 8"><b>5.1</b></a></li>2148 <li class="indline1"><tt>Accept-Language</tt> <a class="iref" href="#rfc.iref.g.2 4"><b>5.4</b></a></li>2149 <li class="indline1"><tt>Accept-Language-v</tt> <a class="iref" href="#rfc.iref.g.2 5"><b>5.4</b></a></li>2150 <li class="indline1"><tt>accept-params</tt> <a class="iref" href="#rfc.iref.g.1 7"><b>5.1</b></a></li>2151 <li class="indline1"><tt>Accept-v</tt> <a class="iref" href="#rfc.iref.g.1 5"><b>5.1</b></a></li>2137 <li class="indline1"><tt>Accept</tt> <a class="iref" href="#rfc.iref.g.13"><b>5.1</b></a></li> 2138 <li class="indline1"><tt>Accept-Charset</tt> <a class="iref" href="#rfc.iref.g.18"><b>5.2</b></a></li> 2139 <li class="indline1"><tt>Accept-Charset-v</tt> <a class="iref" href="#rfc.iref.g.19"><b>5.2</b></a></li> 2140 <li class="indline1"><tt>Accept-Encoding</tt> <a class="iref" href="#rfc.iref.g.20"><b>5.3</b></a></li> 2141 <li class="indline1"><tt>Accept-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.21"><b>5.3</b></a></li> 2142 <li class="indline1"><tt>accept-ext</tt> <a class="iref" href="#rfc.iref.g.17"><b>5.1</b></a></li> 2143 <li class="indline1"><tt>Accept-Language</tt> <a class="iref" href="#rfc.iref.g.23"><b>5.4</b></a></li> 2144 <li class="indline1"><tt>Accept-Language-v</tt> <a class="iref" href="#rfc.iref.g.24"><b>5.4</b></a></li> 2145 <li class="indline1"><tt>accept-params</tt> <a class="iref" href="#rfc.iref.g.16"><b>5.1</b></a></li> 2146 <li class="indline1"><tt>Accept-v</tt> <a class="iref" href="#rfc.iref.g.14"><b>5.1</b></a></li> 2152 2147 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g.8"><b>2.3</b></a></li> 2153 2148 <li class="indline1"><tt>charset</tt> <a class="iref" href="#rfc.iref.g.1"><b>2.1</b></a></li> 2154 <li class="indline1"><tt>codings</tt> <a class="iref" href="#rfc.iref.g.2 3"><b>5.3</b></a></li>2149 <li class="indline1"><tt>codings</tt> <a class="iref" href="#rfc.iref.g.22"><b>5.3</b></a></li> 2155 2150 <li class="indline1"><tt>content-coding</tt> <a class="iref" href="#rfc.iref.g.2"><b>2.2</b></a></li> 2156 <li class="indline1"><tt>content-disposition</tt> <a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li> 2157 <li class="indline1"><tt>content-disposition-v</tt> <a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li> 2158 <li class="indline1"><tt>Content-Encoding</tt> <a class="iref" href="#rfc.iref.g.27"><b>5.5</b></a></li> 2159 <li class="indline1"><tt>Content-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.28"><b>5.5</b></a></li> 2160 <li class="indline1"><tt>Content-Language</tt> <a class="iref" href="#rfc.iref.g.29"><b>5.6</b></a></li> 2161 <li class="indline1"><tt>Content-Language-v</tt> <a class="iref" href="#rfc.iref.g.30"><b>5.6</b></a></li> 2162 <li class="indline1"><tt>Content-Location</tt> <a class="iref" href="#rfc.iref.g.31"><b>5.7</b></a></li> 2163 <li class="indline1"><tt>Content-Location-v</tt> <a class="iref" href="#rfc.iref.g.32"><b>5.7</b></a></li> 2164 <li class="indline1"><tt>Content-MD5</tt> <a class="iref" href="#rfc.iref.g.33"><b>5.8</b></a></li> 2165 <li class="indline1"><tt>Content-MD5-v</tt> <a class="iref" href="#rfc.iref.g.34"><b>5.8</b></a></li> 2166 <li class="indline1"><tt>Content-Type</tt> <a class="iref" href="#rfc.iref.g.35"><b>5.9</b></a></li> 2167 <li class="indline1"><tt>Content-Type-v</tt> <a class="iref" href="#rfc.iref.g.36"><b>5.9</b></a></li> 2168 <li class="indline1"><tt>disp-extension-parm</tt> <a class="iref" href="#rfc.iref.g.45"><b>B.1</b></a></li> 2169 <li class="indline1"><tt>disp-extension-token</tt> <a class="iref" href="#rfc.iref.g.44"><b>B.1</b></a></li> 2170 <li class="indline1"><tt>disposition-parm</tt> <a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li> 2171 <li class="indline1"><tt>disposition-type</tt> <a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li> 2172 <li class="indline1"><tt>entity-body</tt> <a class="iref" href="#rfc.iref.g.13"><b>3.2</b></a></li> 2151 <li class="indline1"><tt>content-disposition</tt> <a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li> 2152 <li class="indline1"><tt>content-disposition-v</tt> <a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li> 2153 <li class="indline1"><tt>Content-Encoding</tt> <a class="iref" href="#rfc.iref.g.26"><b>5.5</b></a></li> 2154 <li class="indline1"><tt>Content-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.27"><b>5.5</b></a></li> 2155 <li class="indline1"><tt>Content-Language</tt> <a class="iref" href="#rfc.iref.g.28"><b>5.6</b></a></li> 2156 <li class="indline1"><tt>Content-Language-v</tt> <a class="iref" href="#rfc.iref.g.29"><b>5.6</b></a></li> 2157 <li class="indline1"><tt>Content-Location</tt> <a class="iref" href="#rfc.iref.g.30"><b>5.7</b></a></li> 2158 <li class="indline1"><tt>Content-Location-v</tt> <a class="iref" href="#rfc.iref.g.31"><b>5.7</b></a></li> 2159 <li class="indline1"><tt>Content-MD5</tt> <a class="iref" href="#rfc.iref.g.32"><b>5.8</b></a></li> 2160 <li class="indline1"><tt>Content-MD5-v</tt> <a class="iref" href="#rfc.iref.g.33"><b>5.8</b></a></li> 2161 <li class="indline1"><tt>Content-Type</tt> <a class="iref" href="#rfc.iref.g.34"><b>5.9</b></a></li> 2162 <li class="indline1"><tt>Content-Type-v</tt> <a class="iref" href="#rfc.iref.g.35"><b>5.9</b></a></li> 2163 <li class="indline1"><tt>disp-extension-parm</tt> <a class="iref" href="#rfc.iref.g.44"><b>B.1</b></a></li> 2164 <li class="indline1"><tt>disp-extension-token</tt> <a class="iref" href="#rfc.iref.g.43"><b>B.1</b></a></li> 2165 <li class="indline1"><tt>disposition-parm</tt> <a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li> 2166 <li class="indline1"><tt>disposition-type</tt> <a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li> 2173 2167 <li class="indline1"><tt>entity-header</tt> <a class="iref" href="#rfc.iref.g.11"><b>3.1</b></a></li> 2174 2168 <li class="indline1"><tt>extension-header</tt> <a class="iref" href="#rfc.iref.g.12"><b>3.1</b></a></li> 2175 <li class="indline1"><tt>filename-parm</tt> <a class="iref" href="#rfc.iref.g.4 3"><b>B.1</b></a></li>2176 <li class="indline1"><tt>language-range</tt> <a class="iref" href="#rfc.iref.g.2 6"><b>5.4</b></a></li>2169 <li class="indline1"><tt>filename-parm</tt> <a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li> 2170 <li class="indline1"><tt>language-range</tt> <a class="iref" href="#rfc.iref.g.25"><b>5.4</b></a></li> 2177 2171 <li class="indline1"><tt>language-tag</tt> <a class="iref" href="#rfc.iref.g.10"><b>2.4</b></a></li> 2178 <li class="indline1"><tt>media-range</tt> <a class="iref" href="#rfc.iref.g.1 6"><b>5.1</b></a></li>2172 <li class="indline1"><tt>media-range</tt> <a class="iref" href="#rfc.iref.g.15"><b>5.1</b></a></li> 2179 2173 <li class="indline1"><tt>media-type</tt> <a class="iref" href="#rfc.iref.g.4"><b>2.3</b></a></li> 2180 <li class="indline1"><tt>MIME-Version</tt> <a class="iref" href="#rfc.iref.g.3 7"><b>A.1</b></a></li>2181 <li class="indline1"><tt>MIME-Version-v</tt> <a class="iref" href="#rfc.iref.g.3 8"><b>A.1</b></a></li>2174 <li class="indline1"><tt>MIME-Version</tt> <a class="iref" href="#rfc.iref.g.36"><b>A.1</b></a></li> 2175 <li class="indline1"><tt>MIME-Version-v</tt> <a class="iref" href="#rfc.iref.g.37"><b>A.1</b></a></li> 2182 2176 <li class="indline1"><tt>parameter</tt> <a class="iref" href="#rfc.iref.g.7"><b>2.3</b></a></li> 2183 2177 <li class="indline1"><tt>subtype</tt> <a class="iref" href="#rfc.iref.g.6"><b>2.3</b></a></li> … … 2274 2268 <li class="indline1"><em>RFC1951</em> <a class="iref" href="#rfc.xref.RFC1951.1">6.2</a>, <a class="iref" href="#RFC1951"><b>9.1</b></a></li> 2275 2269 <li class="indline1"><em>RFC1952</em> <a class="iref" href="#rfc.xref.RFC1952.1">6.2</a>, <a class="iref" href="#RFC1952"><b>9.1</b></a></li> 2276 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#RFC2045"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a> , <a class="iref" href="#rfc.xref.RFC2045.3">A.2</a></li>2270 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#RFC2045"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a></li> 2277 2271 <li class="indline1"><em>RFC2046</em> <a class="iref" href="#rfc.xref.RFC2046.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a>, <a class="iref" href="#rfc.xref.RFC2046.3">3.2.1</a>, <a class="iref" href="#RFC2046"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2046.4">A.2</a><ul class="ind"> 2278 2272 <li class="indline1"><em>Section 4.5.1</em> <a class="iref" href="#rfc.xref.RFC2046.3">3.2.1</a></li>
Note: See TracChangeset
for help on using the changeset viewer.
