[Http-crcsync] General comments on crcsync document

[Pedro R]

Hi Alex,


>Using content-encoding gives issues with e-tag based classical caching in case 
>of proxy-based crccache handling; the crccache will have to translate from 
>the content-encoding of the origin-server to the crcsync content-encoding, in 
>which case it should modify the e-tag (e.g. append ' crcsync' to the value) 
>because the e-tag is associated with the 'entity' (being the encoded 
>content). This will then prevent classical caching based on an e-tag where a 
>server might otherwise have replied with a '304 not modified'  response.

>The idea in the current specification is to make this transparent by 
>remembering the original headers (e.g. content-encoding and e-tag) in the 
>(first compressed) block of the delta-response-body and restoring them in the 
>reconstructed page and obviously also re-encoding the reconstructed page so 
>that the entity-coding and the e-tag match again.

What if instead of appending crcsync to the etag, the crccache server would
append the original encoding?

(instead of etag-crcsync it would be etag-gzip for example).

The client would store that modified etag and when it makes a request to the proxy, the latter
would make a regular conditional GET using the original entity-encoding and the original etag.

304 not modified would work and there would be no need to store the original headers in
an extra block.

Pedro



Op donderdag 9 juli 2009, schreef Pedro R:
> Hi Alex,
>
> >I would expect a client to perform a standard GET request for it's first
> >
> >request to a server. A crcsync-aware server should then advertise it's
> >capability in a response header so that the client can use a delta-request
> >he next time that the user wants to refresh this resource.
> >
> >Obviously this is suboptimal at the moment that a non-crcsync-aware
> >server -from which the client has already received normal responses- gets
> >upgraded to a crcsync-aware server; the first request that the client will
> >send after such an upgrade would still be a normal GETrequest. However,
> > the now crcsync-aware server should at that moment announce it's
> > capability so that the client can switch to delta-requests after all.
> >
> >What do you think?
>
> Sounds good. I don't think it is suboptimal in the case you just referred.
> Only the first GET would be normal, nothing special to take in
> consideration.
>
> But let me a bit more specific. Assuming that the client already knows that
> the server is crcsync capable, in the current implementation of the server
> there is no "Content-Encoding: crcsync" in the response header.
>
> Is there any special reason for not having this header? Allow me to state
> my case.
>
> I am pushing this Content-Encoding header because it will be easier and
> cleaner to implement the client on a Firefox extension. The alternative is
> doable but not desirable, since it involves a patch to Firefox source code.
> Having said this, don't take it as a personal desire just to have less
> work. I think my arguments below are valid.
>
> Using the Content-Encoding header will allow the reuse of existing gzip
> and deflate mechanisms in current browser engines (I know that Internet
> Explorer has "Pluggable Protocols" which allow MIME type conversions -
> exactly how it is done in Firefox/Gecko). Webkit should have a similar
> mechanism, and so should have other engines.
>
> Keep in mind that ALL browsers which use the Gecko layout engine will be
> easily extended the same way I'm extending Firefox (and there are a lot of
> them). This Content-Encoding is the trigger which activates the automatic
> conversion to uncompressed text (given a filter which decodes crcsync, of
> course).
>
> I'm sorry to annoy you with this particular case, but the inclusion or not
> of this Content-Encoding header is an important design decision in the
> client that I am currently coding!
>
> Pedro Ribeiro
>
> Op donderdag 9 juli 2009, schreef Patrick McManus:
> > On Thu, 2009-07-09 at 05:39 -0700, Pedro R wrote:
> > > H
> > > Upon first contact, the client will never send a full "If-Block"
> > > header. It will only send "If-Block: 0", because it does not have
> > > anything in the cache. So constructing the If-Block header does not
> > > have a cost in this situation.
> >
> > What I am saying is that the server cannot construct a better response
> > with if-block: 0 than it could without if-block there at all. Indeed, if
> > there is nothing to diff against, delta isn't much of a strategy. I am
> > opposed to _requiring_ the server to ever do anything in the presence of
> > if-block - that's an implementation decision on the server side.
> > (coincidentally, the doc says "0" means 1 hash.. what hash are you
> > using?) That's mixing capability (advertisement) and execution again.
> >
> > Advertise with an advertising response header. This can certainly be
> > sent even if there is no if-block in the request (see accept-ranges).
> > This is the kind of thing that can be meaningfully required to at least
> > a SHOULD level (noting that it might be cached).
> >
> > If-block ought to be expensive because it ought to carry meaningful
> > information. It seems reasonable not to send one until you have seen
> > something like "accept-crcsync" in a response, but again that's an
> > implementation decision on the client side.. not something for the spec
> > to mandate.
> >
> > OPTIONS is a bit of a red herring. If you want to explicitly probe then
> > that's the way to do it. If you don't want to probe I'm not saying you
> > have to! :)
> >
> > Best Regards,
> > Patirck
> >
> >
> >
> >
> > _______________________________________________
> > Http-crcsync mailing list
> > Http-crcsync at lists.laptop.org
> > http://lists.laptop.org/listinfo/http-crcsync