【转】http协议content-encoding & transfer-encoding

上一篇 / 下一篇  2011-04-10 18:54:14 / 个人分类:知识

http://liwei521930.blog.163.com/blog/static/51521708201012772521807/

content-encoding 有三种gzip,compress,deflate,都是压缩算法content-transfer-encode 只有一种chunking. 

 All content-coding values are case-insensitive. HTTP/1.1 uses
   content-coding values in the Accept-Encoding (section 14.3) and
   Content-Encoding (section 14.11) header fields. Although the value
   describes the content-coding, what is more important is that it
   indicates what decoding mechanism will be required to remove the
   encoding.

   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   content-coding value tokens. Initially, the registry contains the
   following tokens:

   gzip (http://en.wikipedia.org/wiki/Gzip)

         An encoding format produced by the file compression program
        "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a
        Lempel-Ziv coding (LZ77) with a 32 bit CRC.

   compress(http://en.wikipedia.org/wiki/Compress)
        The encoding format produced by the common UNIX file compression
        program "compress". This format is an adaptive Lempel-Ziv-Welch
        coding (LZW).

        Use of program names for the identification of encoding formats
        is not desirable and is discouraged for future encodings. Their
        use here is representative of historical practice, not good
        design. For compatibility with previous implementations of HTTP,
        applications SHOULD consider "x-gzip" and "x-compress" to be
        equivalent to "gzip" and "compress" respectively.

   deflate(http://en.wikipedia.org/wiki/DEFLATE)
        The "zlib" format defined in RFC 1950 [31] in combination with
        the "deflate" compression mechanism described in RFC 1951 [29].

3.6 Transfer Codings

   Transfer-coding values are used to indicate an encoding
   transformation that has been, can be, or may need to be applied to an
   entity-body in order to ensure "safe transport" through the network.
   This differs from a content coding in that the transfer-coding is a
   property of the message, not of the original entity.

       transfer-coding         = "chunked" | transfer-extension
       transfer-extension      = token *( ";" parameter )

   Parameters are in  the form. of attribute/value pairs.

       parameter               = attribute "=" value
       attribute               = token
       value                   = token | quoted-string

   All transfer-coding values are case-insensitive. HTTP/1.1 uses
   transfer-coding values in the TE header field (section 14.39) and in
   the Transfer-Encoding header field (section 14.41).

   Whenever a transfer-coding is applied to a message-body, the set of
   transfer-codings MUST include "chunked", unless the message is
   terminated by closing the connection. When the "chunked" transfer-
   coding is used, it MUST be the last transfer-coding applied to the
   message-body. The "chunked" transfer-coding MUST NOT be applied more
   than once to a message-body. These rules allow the recipient to
   determine the transfer-length of the message (section 4.4).

   Transfer-codings are analogous to the Content-Transfer-Encoding
   values of MIME [7], which were designed to enable safe transport of
   binary data over a 7-bit transport service. However, safe transport
   has a different focus for an 8bit-clean transfer protocol. In HTTP,
   the only unsafe characteristic of message-bodies is the difficulty in
   determining the exact body length (section 7.2.2), or the desire to
   encrypt data over a shared transport.



Fielding, et al.            Standards Track                    [Page 24]

RFC 2616                        HTTP/1.1                       June 1999


   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   transfer-coding value tokens. Initially, the registry contains the
   following tokens: "chunked" (section 3.6.1), "identity" (section
   3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
   (section 3.5).

   New transfer-coding value tokens SHOULD be registered in the same way
   as new content-coding value tokens (section 3.5).

   A server which receives an entity-body with a transfer-coding it does
   not understand SHOULD return 501 (Unimplemented), and close the
   connection. A server MUST NOT send transfer-codings to an HTTP/1.0
   client.

3.6.1 Chunked Transfer Coding

   The chunked encoding modifies the body of a message in order to
   transfer it as a series of chunks, each with its own size indicator,
   followed by an OPTIONAL trailer containing entity-header fields. This
   allows dynamically produced content to be transferred along with the
   information necessary for the recipient to verify that it has
   received the full message.

       Chunked-Body   = *chunk
                        last-chunk
                        trailer
                        CRLF

       chunk          = chunk-size [ chunk-extension ] CRLF
                        chunk-data CRLF
       chunk-size     = 1*HEX
       last-chunk     = 1*("0") [ chunk-extension ] CRLF

       chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
       chunk-ext-name = token
       chunk-ext-val  = token | quoted-string
       chunk-data     = chunk-size(OCTET)
       trailer        = *(entity-header CRLF)

   The chunk-size field is a string of hex digits indicating the size of
   the chunk. The chunked encoding is ended by any chunk whose size is
   zero, followed by the trailer, which is terminated by an empty line.

   The trailer allows the sender to include additional HTTP header
   fields at the end of the message. The Trailer header field can be
   used to indicate which header fields are included in a trailer (see
   section 14.40).




Fielding, et al.            Standards Track                    [Page 25]

RFC 2616                        HTTP/1.1                       June 1999


   A server using chunked transfer-coding in a response MUST NOT use the
   trailer for any header fields unless at least one of the following is
   true:

   a)the request included a TE header field that indicates "trailers" is
     acceptable in the transfer-coding of the  response, as described in
     section 14.39; or,

   b)the server is the origin server for the response, the trailer
     fields consist entirely of optional metadata, and the recipient
     could use the message (in a manner acceptable to the origin server)
     without receiving this metadata.  In other words, the origin server
     is willing to accept the possibility that the trailer fields might
     be silently discarded along the path to the client.

   This requirement prevents an interoperability failure when the
   message is being received by an HTTP/1.1 (or later) proxy and
   forwarded to an HTTP/1.0 recipient. It avoids a situation where
   compliance with the protocol would have necessitated a possibly
   infinite buffer on the proxy.

   An example process for decoding a Chunked-Body is presented in
   appendix 19.4.6.

   All HTTP/1.1 applications MUST be able to receive and decode the
   "chunked" transfer-coding, and MUST ignore chunk-extension extensions
   they do not understand.


TAG:

 

评分:0

我来说两句

我的栏目

日历

« 2024-02-19  
    123
45678910
11121314151617
18192021222324
2526272829  

数据统计

  • 访问量: 30101
  • 日志数: 22
  • 图片数: 3
  • 建立时间: 2011-03-09
  • 更新时间: 2011-05-17

RSS订阅

Open Toolbar