[Http-crcsync] http-sync standard

[Alex Wulms]

Op maandag 20 april 2009, schreef tridge at samba.org:
> Hi Toby,
>
>  > * Use the 226 response type to resolve the caching intermediate proxy
>  > problem.
>
> How would the 226 response type interact with existing proxies that
> don't understand it?
The authors of RFC3229 assume that HTTP 1.0 proxies forward responses that 
they don't understand but that they do not cache them. And that is the 
problem that they try to resolve (e.g. intermediate HTTP 1.0 proxies should 
not cache a delta-encoded response).

See below a full extract of that specific section of the RFC (from 
http://www.ietf.org/rfc/rfc3229.txt):

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


Cheers,
Alex