rfc3229.txt

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

       entity-body
                   |   apply transfer-coding, if any
                   v
       message-body

   This formalization of the HTTP message generation sequence has not
   previously been described.  However, it is clear that Range selection
   needs to be done after the entity tag has been assigned and after any
   content-coding has been applied, and before any transfer-coding is
   applied.  Therefore, this formalization is fully consistent with
   previous practice and specification.

4.1 Relationship between deltas and ranges

   If both Ranges and delta encodings are forms of instance
   manipulation, which should be applied first?  This depends on how the
   Range is being used.

   Ranges are used for two main purposes, at the discretion of the
   requesting client:

      1. to complete a partial response after a premature termination of
         a message transmission.

      2. to obtain just selected sections of an instance.

   In the first use of Range, it would have to be applied after any
   delta encoding, since the intended use is to recover an intact copy
   of the delta-encoded instance.  In the second use of Range, it would
   have to be applied before any delta encoding, because otherwise the





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


   offsets specified in the Range request would be meaningless (the
   client generally cannot know how a server's delta encoding maps
   instance byte offsets to entity byte offsets).

   Therefore, we need a mechanism to allow the client to specify the
   order in which two or more instance-manipulations should be applied.
   This is easily provided as part of the specification of the "A-IM"
   header (see section 10.5.3), where we require that the server apply
   instance-manipulations in the order that they are listed in the "A-
   IM" header.  We also include a "range" literal in the set of
   registered instance-manipulations, to allow the client to specify (by
   its ordering with respect to other instance-manipulations) whether
   range selection is done before or after delta encoding.

   We also need a mechanism for the server to indicate in which order
   two or more instance-manipulations have been applied; this is part of
   the specification of the "IM" header (see section 10.5.2), where we
   follow the same practice used for the "Content-Encoding" header:  the
   "IM" header lists the instance-manipulations in the order that were
   applied (including, perhaps, the special "range" literal).

   A similar issue arises when Ranges are combined with compression.  If
   the client is using a Range to complete a partial response after a
   premature termination of a compressed message, then the Range would
   have to be applied after the compression.  This is feasible in
   unmodified HTTP/1.1, because the compression can be done as a
   content-coding.  However, if the client is using a Range to obtain
   selected sections of an instance, it would normally be able to
   specify offsets only in terms of the uncompressed variant.  If the
   selected portion was large enough to warrant compression, the client
   could request a compressed transfer-coding, but this is a hop-by-hop
   transformation and is not the most efficient approach (especially if
   an HTTP/1.0 proxy is in the path).

   We can resolve this issue by supporting the use of compression as an
   instance-manipulation (as well as as a content-coding or transfer-
   coding), and by using the new mechanism that allows the client to
   specify that the compression instance-manipulation is done after the
   Range instance-manipulation.

   This also allows the client to control whether compression is done
   before or after delta encoding, since some simple differencing
   algorithms (such as the UNIX "diff" command) require post-compression
   of their output to yield the best results.







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


5 Basic mechanisms

   In this section, we explain the concepts behind delta encoding.  This
   is not meant as a formal specification of the proposed extensions;
   see section 10 for that.

5.1 Background: an overview of HTTP cache validation

   When a client has a response in its cache, and wishes to ensure that
   this cache entry is current, HTTP/1.1 allows the client to do a
   "conditional GET", using one of two forms of "cache validators."  In
   the traditional form, available in both HTTP/1.0 and in HTTP/1.1, the
   client may use the "If-Modified-Since" request-header to present to
   the server the "Last-Modified" timestamp (if any) that the server
   provided with the response.  If the server's timestamp for the
   resource has not changed, it may send a response with a status code
   of 304 (Not Modified), which does not transmit the body of the
   resource.  If the timestamp has changed, the server would normally
   send a response with a status code of 200 (OK), which carries a
   complete copy of the resource, and a new Last-Modified timestamp.

   This timestamp-based approach is prone to error because of the lack
   of timestamp resolution: if a resource changes twice during one
   second, the change might not be detectable.  Therefore, HTTP/1.1 also
   allows the server to provide an entity tag with a response.  An
   entity tag is an opaque string, constructed by the server according
   to its own needs; the protocol specification imposes a bare minimum
   of requirements on entity tags.  (In particular, a "strong" entity
   tag must change if the value of the resource changes.) In this case,
   the client may validate its cache entry by sending its conditional
   request using the "If-None-Match" request-header, presenting the
   entity tag associated with the cached response.  (The protocol
   defines several other ways to transmit entity tags, such as the "If-
   Range" header, used for short-circuiting an otherwise necessary round
   trip.) If the presented entity tag matches the server's current tag
   for the resource, the server should send a 304 (Not Modified)
   response.  Otherwise, the server should send a 200 (OK) response,
   along with a complete copy of the resource.

   In the existing HTTP protocol (HTTP/1.0 or HTTP/1.1), a client
   sending a conditional request can expect either of two responses:

      -  status = 200 (OK), with a full copy of the resource, because
         the server's copy of the resource is presumably different from
         the client's cached copy.






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


      -  status = 304 (Not Modified), with no body, because the server's
         copy of the resource is presumably the same as the client's
         cached copy.

   Informally, one could think of these as "deltas" of 100% and 0% of
   the resource, respectively.  Note that these deltas are relative to a
   specific cached response.  That is, a client cannot request a delta
   without specifying, somehow, which two instances of a resource are
   being differenced.  The "new" instance is implicitly the current
   instance that the server would return for an unconditional request,
   and the "old" instance is the one that is currently in the client's
   cache.  The cache validator (last-modified time or entity tag) is
   what is used to communicate to the server the identity of the old
   instance.

5.2 Requesting the transmission of deltas

   In order to support the transmission of actual deltas, an extension
   to HTTP/1.1 needs to provide these features:

      1. A way to mark a request as conditional.

      2. A way to specify the old instance, to which the delta will be
         applied by the client.

      3. A way to indicate that the client is able to apply one or more
         specific forms of delta encoding.

      4. A way to mark a response as being delta-encoded in a particular
         format.

   The first two features are already provided by HTTP/1.1: the presence
   of a conditional request-header (such as "If-Modified-Since" or "If-
   None-Match") marks a request as conditional, and the value of that
   header uniquely specifies the old instance (ignoring the problem of
   last-modified timestamp granularity).

   We defer discussion of the fourth feature, until section 5.6.

   The third feature, a way for the client to indicate that it is able
   to apply deltas (aside from the trivial 0% and 100% deltas), can be
   accomplished by transmitting a list of acceptable delta-encoding
   formats in a request-header field; specifically, the "A-IM" header.
   The presence of this list in a conditional request indicates that the
   client is able to apply delta-encoded cache updates.






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


   For example, a client might send this request:

      GET /foo.html HTTP/1.1
      Host: bar.example.net
      If-None-Match: "123xyz"
      A-IM: vcdiff, diffe, gzip

   The meaning of this request is that:

      -  The client wants to obtain the current value of /foo.html.

      -  It already has a cached response (instance) for that resource,
         whose entity tag is "123xyz".

      -  It is willing to accept delta-encoded updates using either of
         two formats, "diffe" (i.e., output from the UNIX "diff -e"
         command), and "vcdiff".  (Encoding algorithms and formats, such
         as "vcdiff", are described in section 6.)

      -  It is willing to accept responses that have been compressed
         using "gzip," whether or not these are delta-encoded.  (It
         might be useful to compress the output of "diff -e".)  However,
         based on the mandatory ordering constraint specified in section
         10.5.3, if both delta encoding and compression are applied,
         then this "A-IM" request header specifies that compression
         should be done last.

   If, in this example, the server's current entity tag for the resource
   is still "123xyz", then it should simply return a 304 (Not Modified)
   response, as would a traditional server.

   If the entity tag has changed, presumably but not necessarily because
   of a modification of the resource, the server could instead compute
   the delta between the instance whose entity tag was "123xyz" and the
   current instance.

   We defer discussion of what the server needs to store, in order to
   compute deltas, until section 7.

   We note that if a client indicates it is willing to accept deltas,
   but the server does not support this form of instance-manipulation,
   the server will simply ignore this aspect of the request.  (HTTP
   always allows an implementation to ignore a header that is not
   required by a specification that the implementation complies with,
   and the specification of "A-IM" allows the server to ignore an
   instance-manipulation it does not understand.)  So if a server either
   does not implement the A-IM header at all, or does not implement any




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


   of the instance manipulations listed in the A-IM header, it acts as
   if the client had not requested a delta-encoded response: the server
   generates a status-200 response.

5.3 Choice of delta algorithm and format

   The server is not required to transmit a delta-encoded response.  For
   example, the result might be larger than the current size of the
   resource.  The server might not be able to compute a delta for this
   type of resource (e.g., a compressed binary format); the server might
   not have sufficient CPU cycles for the delta computation; the server
   might not support any of the delta formats supported by the client;
   or, the network bandwidth might be high enough that the delay
   involved in computing the delta is not worth the delay avoided by
   sending a smaller response.

   However, if the server does want to compute a delta, and the set of
   encodings it supports has more than one encoding in common with the
   set offered by the client, which encoding should it use?  This is
   mostly at the option of the server, although the client can express
   preferences using "Quality Values" (or "qvalues") in the "A-IM"
   header.  The HTTP/1.1 specification [10] describes qvalues in more
   detail.  (Clients may prefer one delta encoding format over another
   that generates a smaller encoding, if the decoding costs for the
   first format are lower and the client is resource-constrained.)

   Server implementations have a number of possible approaches.  For