rfc3229.txt

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

   example, if CPU cycles are plentiful and network bandwidth is scarce,
   the server might compute each of the possible encodings and then send
   the smallest result.  Or the server might use heuristics to choose an
   encoding format, based on things such as the content-type of the
   resource, the current size of the resource, and the expected amount
   of change between instances of the resource.

   Note that it might pay to cache the deltas internally to the server,
   if a resource is typically requested by several different delta-
   capable clients between modifications.  In this case, the cost of
   computing a delta may be amortized over many responses, and so the
   server might use a more expensive computation.

5.4 Identification of delta-encoded responses

   A response using delta encoding must be identified as such.  This is
   done using the "IM" response-header, specified in section 10.5.2.

   However, a simplistic application of this approach would cause
   serious problems if a delta-encoded response flows through an
   intermediate (proxy) cache that is not cognizant of the delta



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


   mechanism.  Because the Internet still includes a significant number
   of HTTP/1.0 caches, which might never be entirely replaced, and
   because the HTTP specifications insist that message recipients ignore
   any header field that they do not understand, a non-delta-capable
   proxy cache that receives a delta-encoded response might store that
   response, and might later return it to a non-delta-capable client
   that has made a request for the same resource.  This naive client
   would believe that it has received a valid copy of the entire
   resource, with predictably unpleasant results.

   To solve this problem, we propose that delta-encoded responses
   (actually, all instance-manipulated responses) be identified as such
   using a new HTTP status code.  For specificity in the discussion that
   follows, we will use the (currently unassigned) code of 226, with a
   reason phrase of "IM Used".  (We see no benefit in spelling out the
   words "Instance Manipulation Used," since this requires the
   transmission of unnecessary bytes, and this Reason-phrase should not
   normally be seen by human users.)  There is some precedent for this
   approach:  the HTTP/1.1 specification introduces the 206 (Partial
   Content) status code, for the transmission of sub-ranges of a
   resource.  Existing proxies apparently forward responses with unknown
   status codes, and do not attempt to cache them.

   An alternative to using a new status code would be to use the
   "Expires" header to prevent HTTP/1.0 caches from storing the
   response, then use "Cache-Control: max-age" (defined in HTTP/1.1) to
   allow more modern caches to store delta-encoded responses.  This adds
   many bytes to the response headers, and so would reduce the
   effectiveness of delta encoding.  It is also not entirely clear that
   this approach suppresses all caching by all HTTP/1.0 proxies.

      We were reluctant to define an additional status code as part of
      the support for delta encoding.  However, we see no other
      efficient way to remain compatible with the deployed base of
      HTTP/1.0 cache implementations.

5.5 Guaranteeing cache safety

   Although we are not aware of any HTTP/1.1 proxy implementations that
   would attempt to cache a response with an unknown 2xx status code,
   the HTTP/1.1 specification does allow this behavior if the response
   carries an Expires or Cache-Control header field that explicitly
   allows caching.  This would present a problem when a 226 (IM Used)
   response carries such headers.







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


   The solution in that case is to exploit the Cache Control Extensions
   mechanism from the HTTP/1.1 specification.  We define a new cache-
   directive, "im", which indicates that the "no-store" cache-directive
   may be ignored by implementations that conform to the specification
   for the IM and A-IM headers.

   For example, this response:

      HTTP/1.1 226 IM Used
      ETag: "489uhw"
      IM: vcdiff
      Date: Tue, 25 Nov 1997 18:30:05 GMT
      Cache-Control: no-store, im, max-age=30

      ...

   "MUST NOT" be stored by a cache that complies with the HTTP/1.1
   specification (which states that the max-age cache-directive "implies
   that the response is cacheable [...] unless some other, more
   restrictive cache directive is also present.").  However, a cache
   that does comply with the specification for the im cache-directive
   (i.e., a cache that complies with the specification for the A-IM and
   IM header fields, and the 226 status code) ignores the no-store
   directive, and therefore sees the max-age directive as allowing
   caching.

      We are not entirely sure that all HTTP/1.1 caches obey the rule
      that the max-age directive is overridden by the no-store
      directive.  If operational testing reveals this to be a problem,
      more elaborate solutions are possible.

   Warning to origin server implementors: it does not suffice to send

      Vary: If-None-Match, A-IM

   in status-226 responses.  We have discovered at least one scenario
   where this does not prevent a proxy cache that does not implement IM
   and A-IM from incorrectly "validating" a cached 226 response.

5.6 Transmission of delta-encoded responses

   A delta-encoded response differs from a standard response in four
   ways:

      1. It carries a status code of 226 (IM Used).

      2. It carries an "IM" response-header field, indicating which
         delta encoding is used in this response.



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


      3. Its message-body is a delta encoding of the current instance,
         rather than a full copy of the instance.

      4. It might carry several other new headers, as described later in
         this document.

   For example, a response to the request given in section 5.2 might
   look like:

      HTTP/1.1 226 IM Used
      ETag: "489uhw"
      IM: vcdiff
      Date: Tue, 25 Nov 1997 18:30:05 GMT

      ...

   (We do not show the actual contents of the response body, since this
   is a binary format.)

      Note: the Etag header in a 226 response with a delta encoding
      provides the entity tag of the current instance of the resource
      variant.  It is not meaningful to associate an entity tag with the
      delta value, which is not an instance.

5.7 Examples of requests combining Range and delta encoding

   In the example used in section 5.2, the client sends:

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

   and the server either responds with a 304 (Not Modified) response, or
   with the appropriate delta encoding.

   Here are a few more examples, to clarify how the client request
   should be interpreted.

   If the client sends

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





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


   then the meaning is the same as in the example above, except that
   after the delta encoding (and compression, if any) is computed, the
   server then returns only the first 100 bytes of the output of the
   delta encoding.  (If it is shorter than 100 bytes, the entire delta
   encoding is returned.)  Because the "range" token appears last in the
   "A-IM" header, this tells the origin server to apply any range
   selection after the other instance-manipulations.

   The interaction between the If-Range mechanism and delta encoding is
   somewhat complex.  (If-Range means, informally, "if the entity is
   unchanged, send me the part(s) that I am missing; otherwise, send me
   the entire new entity.")  Here is an example that should clarify the
   use of this combination.

   Suppose that the client wants to have the complete current instance
   of http://bar.example.net/foo.html.  It already has a (complete)
   cache entry for this URI, with entity tag "A", so it issues this
   request:

      GET /foo.html HTTP/1.1
      host: bar.example.net
      If-None-Match: "A"
      A-IM: vcdiff

   Suppose that the server's current instance has entity tag "B", and
   that the server also has retained a copy of the instance with entity
   tag "A".  Then, the server could compute the difference between "B"
   and "A", and respond with:

      HTTP/1.1 226 IM Used
      Etag: "B"
      IM: vcdiff
      Date: Tue, 25 Nov 1997 18:30:05 GMT
      Content-Length: 1000

      ...

   but the network connection is terminated after the client has
   received exactly 900 bytes of the message body for the delta-encoded
   content.

   The client wants to retrieve the remaining 100 bytes of the delta
   encoding that was being sent in the interrupted response.  It
   therefore should send:







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


      GET /foo.html HTTP/1.1
      host: bar.example.net
      If-None-Match: "A"
      If-Range: "B"
      A-IM: vcdiff,range
      Range: bytes=900-

   This rather elaborate request has a well-defined meaning, which
   depends on the current entity tag Tcur of the instance when the
   server receives the request:

   Tcur = "A"      (i.e., for some reason, the instance has reverted to
                   the value already in the client's cache).  The server
                   should return a 304 (Not Modified) response, as
                   required by the HTTP/1.1 specification for "If-None-
                   Match".

   Tcur = "B"      (i.e., the instance has not changed again).  The
                   HTTP/1.1 specification for "If-None-Match", in this
                   case, is that the header field is ignored (by a
                   server that does not understand delta encoding).
                   Therefore, this is equivalent to the client's
                   previous request, except that the Range selection is
                   applied after the vcdiff instance manipulation (if
                   both are to be applied).  So the (delta-aware) server
                   again computes the delta between the "A" instance and
                   the "B" instance (or uses a cached computation of the
                   delta), then applies the Range selection, and returns
                   a 226 (IM Used) response, with an message-body
                   containing bytes 900 to 999 of the result of the
                   vcdiff encoding, with an "IM:vcdiff,range" response
                   header.

   Tcur = "C"      (i.e., the instance has changed again).  In this
                   case, the HTTP/1.1 specification for "If-None-Match"
                   again means that this is equivalent to an
                   unconditional request for the current instance.  The
                   specification for "If-Range" requires the server to