rfc3229.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,453 行 · 第 1/5 页

      5. Interoperate with HTTP/1.0 and HTTP/1.1.

      6. Be fully optional for clients, proxies, and servers.

      7. Allow moderately simple implementations.

   The goals do not include:

      -  Reducing the number of HTTP requests sent to an origin server.

      -  Reducing the size of every HTTP message.

      -  Increasing the cache-hit ratio of HTTP caches.

      -  Allowing excessively simplistic implementations of delta
         encoding.

      -  Delta encoding of request messages, or of responses to methods
         other than GET.

         Nothing in this specification specifically precludes the use of
         a delta encoding for the body of a PUT request.  However, no
         mechanism currently exists for the client to discover if the
         server can interpret such messages, and so we do not attempt to
         specify how they might be used.

3 Terminology

   HTTP/1.1 [10] defines the following terms:

   resource        A network data object or service that can be
                   identified by a URI, as defined in section 3.2.
                   Resources may be available in multiple
                   representations (e.g. multiple languages, data
                   formats, size, resolutions) or vary in other ways.

   entity          The information transferred as the payload of a
                   request or response.  An entity consists of
                   metainformation in the form of entity-header fields
                   and content in the form of an entity-body, as
                   described in section 7.




Mogul, et al.               Standards Track                     [Page 6]

RFC 3229                 Delta encoding in HTTP             January 2002


   variant         A resource may have one, or more than one,
                   representation(s) associated with it at any given
                   instant.  Each of these representations is termed a
                   `variant.' Use of the term `variant' does not
                   necessarily imply that the resource is subject to
                   content negotiation.

   The dictionary definition for "entity" is "something that has
   separate and distinct existence and objective or conceptual reality"
   [21].  Unfortunately, the definition for "entity" in HTTP/1.1 is
   similar to that used in MIME [12], based on a false analogy between
   MIME and HTTP.

   In MIME, electronic mail messages do have distinct and separate
   existences.  MIME defines "entity" as something that "refers
   specifically to the MIME-defined header fields and contents of either
   a message or one of the parts in the body of a multipart entity."

   In HTTP, however, a response message to a GET does not have a
   distinct and separate existence.  Rather, it reflects the current
   state of a resource (or a variant, subject to a set of constraints).
   The HTTP/1.1 specification has no term to describe "the value that
   would be returned in response to a GET request at the current time
   for the selected variant of the specified resource."  This leads to
   awkward wordings in the HTTP/1.1 specification in places where this
   concept is necessary.

   To express this concept, we define a new term, for use in this
   document:

   instance        The entity that would be returned in a status-200
                   response to a GET request, at the current time, for
                   the selected variant of the specified resource, with
                   the application of zero or more content-codings, but
                   without the application of any instance manipulations
                   (see below) or transfer-codings.

   It is convenient to think of an entity tag, in HTTP/1.1, as being
   associated with an instance, rather than an entity.  That is, for a
   given resource, two different response messages might include the
   same entity tag, but two different instances of the resource should
   never be associated with the same (strong) entity tag.

   We will informally use the term "delta," in this document, to mean an
   HTTP response encoded as the difference between two instances.






Mogul, et al.               Standards Track                     [Page 7]

RFC 3229                 Delta encoding in HTTP             January 2002


   More formally, delta encodings are members of a potentially larger
   class of transformations on instances, leading to this new term:

   instance manipulation
                   An operation on one or more instances which may
                   result in an instance being conveyed from server to
                   client in parts, or in more than one response
                   message.  For example, a range selection or a delta
                   encoding.  Instance manipulations are end-to-end, and
                   often involve the use of a cache at the client.

   For reasons that will become clear later on, it is convenient to
   think about subrange selection as a form of instance manipulation.
   In some contexts, compression might also be treated as an instance
   manipulation, rather than as a content-coding or transfer-coding.

4 The HTTP message-generation sequence

   HTTP/1.1 supports a number of different transformations on the body
   of a value:

   Content-coding  According to the specification, "Content coding
                   values indicate an encoding transformation that has
                   been or can be applied to an entity.  Content codings
                   are primarily used to allow a document to be
                   compressed or otherwise usefully transformed without
                   losing the identity of its underlying media type and
                   without loss of information.  Frequently, the entity
                   is stored in coded form, transmitted directly, and
                   only decoded by the recipient."  Content-codings are
                   normally end-to-end transformations; i.e., once
                   applied at the sender, they are not removed except at
                   the ultimate recipient.  An intermediate server may
                   apply a content-coding, in appropriate circumstances.

   Transfer-coding According to the specification, "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-codings are explicitly hop-by-hop
                   transformations (although, as an optimization, an
                   intermediate proxy may store the transfer-coded
                   version of a message if this behavior is not
                   inconsistent with its externally visible function.)




Mogul, et al.               Standards Track                     [Page 8]

RFC 3229                 Delta encoding in HTTP             January 2002


   Ranges          An HTTP client, using the Range header, may request
                   that the server return one or more subranges of the
                   instance, rather than the entire instance value.
                   HTTP/1.1 only supports byte-ranges, although there is
                   some possibility that future extensions will allow
                   for other kinds of range-specifiers (such as chapters
                   of a document).

   A client signals its willingness to receive a content-coding by
   sending an "Accept-Encoding" header, listing the set of content-
   codings that it understands.  It may optionally include information
   about which content-codings it prefers.  If a server uses any non-
   identity content-coding(s), it includes a "Content-Encoding" header
   field in the response, listing these content-codings in their order
   of application.

   RFC 2068 [9] did not include an analogous mechanism for negotiating
   the use of transfer-codings, although it does include an analogous
   "Transfer-Encoding" header for marking the response.  A new "TE"
   header has since been added to HTTP/1.1 [10], analogous to the
   "Accept-Encoding" header.

   In this document, we add new, optional message headers to support the
   use of instance manipulations.  A client signals its willingness to
   receive an instance-manipulation by sending an "A-IM" header (short
   for "Accept-Instance-Manipulation", which is far too long to spell
   out), analogous to the "Accept-Encoding" header.  Similarly, a server
   lists the set of instance-manipulations it has applied using an "IM"
   header.

   One must understand the relationship between these transformations in
   order to see how delta encoding applies to HTTP responses.

   Conceptually, the various transformations are applied in the
   following sequence:

      1. Upon receiving a GET request, the server uses the URI in the
         request to identify the requested resource.

      2. Optionally, it uses information from the request (and perhaps
         additional information) to select a variant of that resource.

      3. At this point, the server may apply a non-identity content-
         coding to the instance, or one might have been inherent in its
         generation.  This also results in a Content-Encoding header.






Mogul, et al.               Standards Track                     [Page 9]

RFC 3229                 Delta encoding in HTTP             January 2002


      4. The result of the first three steps, at the time when the
         request is processed, is an instance.  The instance includes a
         body (possibly empty) and possibly some instance headers.  The
         entity tag, if any, is assigned at this point.  That is, an
         entity tag is associated with an instance, NOT an entity.

      5. The server may then apply an instance-manipulation.  For
         example, if the request included a Range header, the server may
         optionally produce a range response, consisting of the original
         set of headers, a Content-Range header, and the appropriate
         range(s) from the (possibly encoded) body.  Delta encodings are
         instance-manipulations, and are computed at this stage.

      6. The result of the fifth step becomes the entity, consisting of
         entity headers and an entity body.

      7. The server may then apply a non-identity transfer-coding; on-
         the-fly compression could be done in this step.  If so, a
         Transfer-Encoding header is added to the message.

      8. The results of the seventh step is the message, consisting of a
         message body (the transfer-coded version of the entity body),
         the entity headers, and additional response and general
         headers.

      Note: Section 14.13 of the HTTP/1.1 specification [10] says "The
      Content-Length entity-header field indicates the size of the
      entity-body."  In other words, Content-Length measures the length
      of an entity, not of an instance or of a variant.  For example, if
      the message is a delta encoding, Content-Length gives the length
      of the delta encoding, not the length of the current instance.




















Mogul, et al.               Standards Track                    [Page 10]

RFC 3229                 Delta encoding in HTTP             January 2002


   Diagrammatically, the sequence is:

       datatype        operation leading to next datatype
       ========        ==================================
       resource
                   |   choose acceptable variant, if needed
                   v
       variant
                   |   apply content-coding, if any
                   v

                   |   compute/assign entity tag
                   v
       instance
                   |   apply instance manipulation, if any
                   v      (delta encoding, range selection, etc.)