deflate The "zlib" format defined in RFC 1950[31] in combination with
        the "deflate" compression mechanism described in RFC 1951[29].

   New content-coding value tokens should be registered; to allow
   interoperability between clients and servers, specifications of the
   content coding algorithms needed to implement a new value should be
   publicly available and adequate for independent implementation, and
   conform to the purpose of content coding defined in this section.

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

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

   Transfer codings are analogous to the Content-Transfer-Encoding
   values of MIME , 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.

   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 footer 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.






 
RFC 2068                        HTTP/1.1                    January 1997


       Chunked-Body   = *chunk
                        "0" CRLF
                        footer
                        CRLF

       chunk          = chunk-size [ chunk-ext ] CRLF
                        chunk-data CRLF

       hex-no-zero    = <HEX excluding "0">

       chunk-size     = hex-no-zero *HEX
       chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
       chunk-ext-name = token
       chunk-ext-val  = token | quoted-string
       chunk-data     = chunk-size(OCTET)

       footer         = *entity-header

   The chunked encoding is ended by a zero-sized chunk followed by the
   footer, which is terminated by an empty line. The purpose of the
   footer is to provide an efficient way to supply information about an
   entity that is generated dynamically; applications MUST NOT send
   header fields in the footer which are not explicitly defined as being
   appropriate for the footer, such as Content-MD5 or future extensions
   to HTTP for digital signatures or other facilities.

   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 transfer coding extensions
   they do not understand. 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.7 Media Types

   HTTP uses Internet Media Types  in the Content-Type (section 14.18)
   and Accept (section 14.1) header fields in order to provide open and
   extensible data typing and type negotiation.

          media-type     = type "/" subtype *( ";" parameter )
          type           = token
          subtype        = token

   Parameters may follow the type/subtype in the form of attribute/value
   pairs.