Ignore:
Timestamp:
Mar 30, 2012, 8:57:47 AM (8 years ago)
Author:
julian.reschke@…
Message:

Step 9 of p2/p3-merge (see #351)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1646 r1647  
    48904890</references>
    48914891
     4892<section title="Differences between HTTP and MIME" anchor="differences.between.http.and.mime">
     4893<t>
     4894   HTTP/1.1 uses many of the constructs defined for Internet Mail (<xref target="RFC5322"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to
     4895   allow a message body to be transmitted in an open variety of
     4896   representations and with extensible mechanisms. However, RFC 2045
     4897   discusses mail, and HTTP has a few features that are different from
     4898   those described in MIME. These differences were carefully chosen
     4899   to optimize performance over binary connections, to allow greater
     4900   freedom in the use of new media types, to make date comparisons
     4901   easier, and to acknowledge the practice of some early HTTP servers
     4902   and clients.
     4903</t>
     4904<t>
     4905   This appendix describes specific areas where HTTP differs from MIME.
     4906   Proxies and gateways to strict MIME environments &SHOULD; be
     4907   aware of these differences and provide the appropriate conversions
     4908   where necessary. Proxies and gateways from MIME environments to HTTP
     4909   also need to be aware of the differences because some conversions
     4910   might be required.
     4911</t>
     4912
     4913<section title="MIME-Version" anchor="mime-version">
     4914  <iref primary="true" item="MIME-Version header field" x:for-anchor=""/>
     4915  <iref primary="true" item="Header Fields" subitem="MIME-Version" x:for-anchor=""/>
     4916  <x:anchor-alias value="MIME-Version"/>
     4917<t>
     4918   HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages &MAY;
     4919   include a single MIME-Version header field to indicate what
     4920   version of the MIME protocol was used to construct the message. Use
     4921   of the MIME-Version header field indicates that the message is in
     4922   full conformance with the MIME protocol (as defined in <xref target="RFC2045"/>).
     4923   Proxies/gateways are responsible for ensuring full conformance (where
     4924   possible) when exporting HTTP messages to strict MIME environments.
     4925</t>
     4926<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="MIME-Version"/>
     4927  <x:ref>MIME-Version</x:ref> = 1*<x:ref>DIGIT</x:ref> "." 1*<x:ref>DIGIT</x:ref>
     4928</artwork></figure>
     4929<t>
     4930   MIME version "1.0" is the default for use in HTTP/1.1. However,
     4931   HTTP/1.1 message parsing and semantics are defined by this document
     4932   and not the MIME specification.
     4933</t>
     4934</section>
     4935
     4936<section title="Conversion to Canonical Form" anchor="conversion.to.canonical.form">
     4937<t>
     4938   MIME requires that an Internet mail body-part be converted to
     4939   canonical form prior to being transferred, as described in <xref target="RFC2049" x:fmt="of" x:sec="4"/>.
     4940   <xref target="canonicalization.and.text.defaults"/> of this document describes the forms
     4941   allowed for subtypes of the "text" media type when transmitted over
     4942   HTTP. <xref target="RFC2046"/> requires that content with a type of "text" represent
     4943   line breaks as CRLF and forbids the use of CR or LF outside of line
     4944   break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
     4945   line break within text content when a message is transmitted over
     4946   HTTP.
     4947</t>
     4948<t>
     4949   Where it is possible, a proxy or gateway from HTTP to a strict MIME
     4950   environment &SHOULD; translate all line breaks within the text media
     4951   types described in <xref target="canonicalization.and.text.defaults"/>
     4952   of this document to the RFC 2049
     4953   canonical form of CRLF. Note, however, that this might be complicated
     4954   by the presence of a Content-Encoding and by the fact that HTTP
     4955   allows the use of some character encodings which do not use octets 13 and
     4956   10 to represent CR and LF, respectively, as is the case for some multi-byte
     4957   character encodings.
     4958</t>
     4959<t>
     4960   Conversion will break any cryptographic
     4961   checksums applied to the original content unless the original content
     4962   is already in canonical form. Therefore, the canonical form is
     4963   recommended for any content that uses such checksums in HTTP.
     4964</t>
     4965</section>
     4966
     4967
     4968<section title="Conversion of Date Formats" anchor="conversion.of.date.formats">
     4969<t>
     4970   HTTP/1.1 uses a restricted set of date formats (&http-date;) to
     4971   simplify the process of date comparison. Proxies and gateways from
     4972   other protocols &SHOULD; ensure that any Date header field present in a
     4973   message conforms to one of the HTTP/1.1 formats and rewrite the date
     4974   if necessary.
     4975</t>
     4976</section>
     4977
     4978<section title="Introduction of Content-Encoding" anchor="introduction.of.content-encoding">
     4979<t>
     4980   MIME does not include any concept equivalent to HTTP/1.1's
     4981   Content-Encoding header field. Since this acts as a modifier on the
     4982   media type, proxies and gateways from HTTP to MIME-compliant
     4983   protocols &MUST; either change the value of the Content-Type header
     4984   field or decode the representation before forwarding the message. (Some
     4985   experimental applications of Content-Type for Internet mail have used
     4986   a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform
     4987   a function equivalent to Content-Encoding. However, this parameter is
     4988   not part of the MIME standards).
     4989</t>
     4990</section>
     4991
     4992<section title="No Content-Transfer-Encoding" anchor="no.content-transfer-encoding">
     4993  <iref item="Content-Transfer-Encoding header field" x:for-anchor=""/>
     4994  <iref item="Header Fields" subitem="Content-Transfer-Encoding" x:for-anchor=""/>
     4995<t>
     4996   HTTP does not use the Content-Transfer-Encoding field of MIME.
     4997   Proxies and gateways from MIME-compliant protocols to HTTP &MUST;
     4998   remove any Content-Transfer-Encoding
     4999   prior to delivering the response message to an HTTP client.
     5000</t>
     5001<t>
     5002   Proxies and gateways from HTTP to MIME-compliant protocols are
     5003   responsible for ensuring that the message is in the correct format
     5004   and encoding for safe transport on that protocol, where "safe
     5005   transport" is defined by the limitations of the protocol being used.
     5006   Such a proxy or gateway &SHOULD; label the data with an appropriate
     5007   Content-Transfer-Encoding if doing so will improve the likelihood of
     5008   safe transport over the destination protocol.
     5009</t>
     5010</section>
     5011
     5012<section title="Introduction of Transfer-Encoding" anchor="introduction.of.transfer-encoding">
     5013<t>
     5014   HTTP/1.1 introduces the Transfer-Encoding header field (&header-transfer-encoding;).
     5015   Proxies/gateways &MUST; remove any transfer-coding prior to
     5016   forwarding a message via a MIME-compliant protocol.
     5017</t>
     5018</section>
     5019
     5020<section title="MHTML and Line Length Limitations" anchor="mhtml.line.length">
     5021<t>
     5022   HTTP implementations which share code with MHTML <xref target="RFC2557"/> implementations
     5023   need to be aware of MIME line length limitations. Since HTTP does not
     5024   have this limitation, HTTP does not fold long lines. MHTML messages
     5025   being transported by HTTP follow all conventions of MHTML, including
     5026   line length limitations and folding, canonicalization, etc., since
     5027   HTTP transports all message-bodies as payload (see <xref target="multipart.types"/>) and
     5028   does not interpret the content or any MIME header lines that might be
     5029   contained therein.
     5030</t>
     5031</section>
     5032</section>
     5033
     5034<section title="Additional Features" anchor="additional.features">
     5035<t>
     5036   <xref target="RFC1945"/> and <xref target="RFC2068"/> document protocol elements used by some
     5037   existing HTTP implementations, but not consistently and correctly
     5038   across most HTTP/1.1 applications. Implementors are advised to be
     5039   aware of these features, but cannot rely upon their presence in, or
     5040   interoperability with, other HTTP/1.1 applications. Some of these
     5041   describe proposed experimental features, and some describe features
     5042   that experimental deployment found lacking that are now addressed in
     5043   the base HTTP/1.1 specification.
     5044</t>
     5045<t>
     5046   A number of other header fields, such as Content-Disposition and Title,
     5047   from SMTP and MIME are also often implemented (see <xref target="RFC6266"/>
     5048   and <xref target="RFC2076"/>).
     5049</t>
     5050</section>
     5051
    48925052<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    48935053<t>
     
    49795139  correctly in the description of the Via header field in &header-via;.
    49805140  (<xref target="header.server"/>)
     5141</t>
     5142<t>
     5143  Clarify contexts that charset is used in.
     5144  (<xref target="character.sets"/>)
     5145</t>
     5146<t>
     5147  Registration of Content Codings now requires IETF Review
     5148  (<xref target="content.coding.registry"/>)
     5149</t>
     5150<t>
     5151  Remove the default character encoding for text media types; the default
     5152  now is whatever the media type definition says.
     5153  (<xref target="canonicalization.and.text.defaults"/>)
     5154</t>
     5155<t>
     5156  Change ABNF productions for header fields to only define the field value.
     5157  (<xref target="header.field.definitions"/>)
     5158</t>
     5159<t>
     5160  Remove definition of Content-MD5 header field because it was inconsistently
     5161  implemented with respect to partial responses, and also because of known
     5162  deficiencies in the hash algorithm itself (see <xref target="RFC6151"/> for details).
     5163  (<xref target="header.field.definitions"/>)
     5164</t>
     5165<t>
     5166  Remove ISO-8859-1 special-casing in Accept-Charset.
     5167  (<xref target="header.accept-charset"/>)
     5168</t>
     5169<t>
     5170  Remove base URI setting semantics for Content-Location due to poor
     5171  implementation support, which was caused by too many broken servers emitting
     5172  bogus Content-Location header fields, and also the potentially undesirable effect
     5173  of potentially breaking relative links in content-negotiated resources.
     5174  (<xref target="header.content-location"/>)
     5175</t>
     5176<t>
     5177  Remove reference to non-existant identity transfer-coding value tokens.
     5178  (<xref target="no.content-transfer-encoding"/>)
     5179</t>
     5180<t>
     5181  Remove discussion of Content-Disposition header field, it is now defined
     5182  by <xref target="RFC6266"/>.
     5183  (<xref target="additional.features"/>)
    49815184</t>
    49825185</section>
     
    61246327</section>
    61256328
    6126 <section title="Differences between HTTP and MIME" anchor="differences.between.http.and.mime">
    6127 <t>
    6128    HTTP/1.1 uses many of the constructs defined for Internet Mail (<xref target="RFC5322"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to
    6129    allow a message body to be transmitted in an open variety of
    6130    representations and with extensible mechanisms. However, RFC 2045
    6131    discusses mail, and HTTP has a few features that are different from
    6132    those described in MIME. These differences were carefully chosen
    6133    to optimize performance over binary connections, to allow greater
    6134    freedom in the use of new media types, to make date comparisons
    6135    easier, and to acknowledge the practice of some early HTTP servers
    6136    and clients.
    6137 </t>
    6138 <t>
    6139    This appendix describes specific areas where HTTP differs from MIME.
    6140    Proxies and gateways to strict MIME environments &SHOULD; be
    6141    aware of these differences and provide the appropriate conversions
    6142    where necessary. Proxies and gateways from MIME environments to HTTP
    6143    also need to be aware of the differences because some conversions
    6144    might be required.
    6145 </t>
    6146 
    6147 <section title="MIME-Version" anchor="mime-version">
    6148   <iref primary="true" item="MIME-Version header field" x:for-anchor=""/>
    6149   <iref primary="true" item="Header Fields" subitem="MIME-Version" x:for-anchor=""/>
    6150   <x:anchor-alias value="MIME-Version"/>
    6151 <t>
    6152    HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages &MAY;
    6153    include a single MIME-Version header field to indicate what
    6154    version of the MIME protocol was used to construct the message. Use
    6155    of the MIME-Version header field indicates that the message is in
    6156    full conformance with the MIME protocol (as defined in <xref target="RFC2045"/>).
    6157    Proxies/gateways are responsible for ensuring full conformance (where
    6158    possible) when exporting HTTP messages to strict MIME environments.
    6159 </t>
    6160 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="MIME-Version"/>
    6161   <x:ref>MIME-Version</x:ref> = 1*<x:ref>DIGIT</x:ref> "." 1*<x:ref>DIGIT</x:ref>
    6162 </artwork></figure>
    6163 <t>
    6164    MIME version "1.0" is the default for use in HTTP/1.1. However,
    6165    HTTP/1.1 message parsing and semantics are defined by this document
    6166    and not the MIME specification.
    6167 </t>
    6168 </section>
    6169 
    6170 <section title="Conversion to Canonical Form" anchor="conversion.to.canonical.form">
    6171 <t>
    6172    MIME requires that an Internet mail body-part be converted to
    6173    canonical form prior to being transferred, as described in <xref target="RFC2049" x:fmt="of" x:sec="4"/>.
    6174    <xref target="canonicalization.and.text.defaults"/> of this document describes the forms
    6175    allowed for subtypes of the "text" media type when transmitted over
    6176    HTTP. <xref target="RFC2046"/> requires that content with a type of "text" represent
    6177    line breaks as CRLF and forbids the use of CR or LF outside of line
    6178    break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
    6179    line break within text content when a message is transmitted over
    6180    HTTP.
    6181 </t>
    6182 <t>
    6183    Where it is possible, a proxy or gateway from HTTP to a strict MIME
    6184    environment &SHOULD; translate all line breaks within the text media
    6185    types described in <xref target="canonicalization.and.text.defaults"/>
    6186    of this document to the RFC 2049
    6187    canonical form of CRLF. Note, however, that this might be complicated
    6188    by the presence of a Content-Encoding and by the fact that HTTP
    6189    allows the use of some character encodings which do not use octets 13 and
    6190    10 to represent CR and LF, respectively, as is the case for some multi-byte
    6191    character encodings.
    6192 </t>
    6193 <t>
    6194    Conversion will break any cryptographic
    6195    checksums applied to the original content unless the original content
    6196    is already in canonical form. Therefore, the canonical form is
    6197    recommended for any content that uses such checksums in HTTP.
    6198 </t>
    6199 </section>
    6200 
    6201 
    6202 <section title="Conversion of Date Formats" anchor="conversion.of.date.formats">
    6203 <t>
    6204    HTTP/1.1 uses a restricted set of date formats (&http-date;) to
    6205    simplify the process of date comparison. Proxies and gateways from
    6206    other protocols &SHOULD; ensure that any Date header field present in a
    6207    message conforms to one of the HTTP/1.1 formats and rewrite the date
    6208    if necessary.
    6209 </t>
    6210 </section>
    6211 
    6212 <section title="Introduction of Content-Encoding" anchor="introduction.of.content-encoding">
    6213 <t>
    6214    MIME does not include any concept equivalent to HTTP/1.1's
    6215    Content-Encoding header field. Since this acts as a modifier on the
    6216    media type, proxies and gateways from HTTP to MIME-compliant
    6217    protocols &MUST; either change the value of the Content-Type header
    6218    field or decode the representation before forwarding the message. (Some
    6219    experimental applications of Content-Type for Internet mail have used
    6220    a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform
    6221    a function equivalent to Content-Encoding. However, this parameter is
    6222    not part of the MIME standards).
    6223 </t>
    6224 </section>
    6225 
    6226 <section title="No Content-Transfer-Encoding" anchor="no.content-transfer-encoding">
    6227   <iref item="Content-Transfer-Encoding header field" x:for-anchor=""/>
    6228   <iref item="Header Fields" subitem="Content-Transfer-Encoding" x:for-anchor=""/>
    6229 <t>
    6230    HTTP does not use the Content-Transfer-Encoding field of MIME.
    6231    Proxies and gateways from MIME-compliant protocols to HTTP &MUST;
    6232    remove any Content-Transfer-Encoding
    6233    prior to delivering the response message to an HTTP client.
    6234 </t>
    6235 <t>
    6236    Proxies and gateways from HTTP to MIME-compliant protocols are
    6237    responsible for ensuring that the message is in the correct format
    6238    and encoding for safe transport on that protocol, where "safe
    6239    transport" is defined by the limitations of the protocol being used.
    6240    Such a proxy or gateway &SHOULD; label the data with an appropriate
    6241    Content-Transfer-Encoding if doing so will improve the likelihood of
    6242    safe transport over the destination protocol.
    6243 </t>
    6244 </section>
    6245 
    6246 <section title="Introduction of Transfer-Encoding" anchor="introduction.of.transfer-encoding">
    6247 <t>
    6248    HTTP/1.1 introduces the Transfer-Encoding header field (&header-transfer-encoding;).
    6249    Proxies/gateways &MUST; remove any transfer-coding prior to
    6250    forwarding a message via a MIME-compliant protocol.
    6251 </t>
    6252 </section>
    6253 
    6254 <section title="MHTML and Line Length Limitations" anchor="mhtml.line.length">
    6255 <t>
    6256    HTTP implementations which share code with MHTML <xref target="RFC2557"/> implementations
    6257    need to be aware of MIME line length limitations. Since HTTP does not
    6258    have this limitation, HTTP does not fold long lines. MHTML messages
    6259    being transported by HTTP follow all conventions of MHTML, including
    6260    line length limitations and folding, canonicalization, etc., since
    6261    HTTP transports all message-bodies as payload (see <xref target="multipart.types"/>) and
    6262    does not interpret the content or any MIME header lines that might be
    6263    contained therein.
    6264 </t>
    6265 </section>
    6266 </section>
    6267 
    6268 <section title="Additional Features" anchor="additional.features">
    6269 <t>
    6270    <xref target="RFC1945"/> and <xref target="RFC2068"/> document protocol elements used by some
    6271    existing HTTP implementations, but not consistently and correctly
    6272    across most HTTP/1.1 applications. Implementors are advised to be
    6273    aware of these features, but cannot rely upon their presence in, or
    6274    interoperability with, other HTTP/1.1 applications. Some of these
    6275    describe proposed experimental features, and some describe features
    6276    that experimental deployment found lacking that are now addressed in
    6277    the base HTTP/1.1 specification.
    6278 </t>
    6279 <t>
    6280    A number of other header fields, such as Content-Disposition and Title,
    6281    from SMTP and MIME are also often implemented (see <xref target="RFC6266"/>
    6282    and <xref target="RFC2076"/>).
    6283 </t>
    6284 </section>
    6285 
    6286 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616-3">
    6287 <t>
    6288   Clarify contexts that charset is used in.
    6289   (<xref target="character.sets"/>)
    6290 </t>
    6291 <t>
    6292   Registration of Content Codings now requires IETF Review
    6293   (<xref target="content.coding.registry"/>)
    6294 </t>
    6295 <t>
    6296   Remove the default character encoding for text media types; the default
    6297   now is whatever the media type definition says.
    6298   (<xref target="canonicalization.and.text.defaults"/>)
    6299 </t>
    6300 <t>
    6301   Change ABNF productions for header fields to only define the field value.
    6302   (<xref target="header.field.definitions"/>)
    6303 </t>
    6304 <t>
    6305   Remove definition of Content-MD5 header field because it was inconsistently
    6306   implemented with respect to partial responses, and also because of known
    6307   deficiencies in the hash algorithm itself (see <xref target="RFC6151"/> for details).
    6308   (<xref target="header.field.definitions"/>)
    6309 </t>
    6310 <t>
    6311   Remove ISO-8859-1 special-casing in Accept-Charset.
    6312   (<xref target="header.accept-charset"/>)
    6313 </t>
    6314 <t>
    6315   Remove base URI setting semantics for Content-Location due to poor
    6316   implementation support, which was caused by too many broken servers emitting
    6317   bogus Content-Location header fields, and also the potentially undesirable effect
    6318   of potentially breaking relative links in content-negotiated resources.
    6319   (<xref target="header.content-location"/>)
    6320 </t>
    6321 <t>
    6322   Remove reference to non-existant identity transfer-coding value tokens.
    6323   (<xref target="no.content-transfer-encoding"/>)
    6324 </t>
    6325 <t>
    6326   Remove discussion of Content-Disposition header field, it is now defined
    6327   by <xref target="RFC6266"/>.
    6328   (<xref target="additional.features"/>)
    6329 </t>
    6330 </section>
    63316329
    63326330<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log3">
Note: See TracChangeset for help on using the changeset viewer.