[Http-crcsync] http-sync standard

Toby Collett thjc at plan9.net.nz
Sat Apr 18 19:37:32 EDT 2009


Having finally got a chance to read the RFC last weekend it raises a few
interesting points.
1) It should be relatively straight forward to make our 'new' standard an
addition to this one, which takes a lot of the heavy lifting off the
definition work
2) There are interesting points raised about caching proxies
3) There are some ideas included in the RFC around hinting to caches how
long they should keep data around.

Point 2 is the most important, in the delta encoding RFC they describe the
problems caused by naive caching proxies caching a delta response from a
server and then using this with an alternate client. The solution they
propose is a new response type (i think a 226 return code instead of a 200
one). In our smart proxy case the 'client' proxy would need to capture this
and turn it into a 200 response once it has finished decoding the message.

So my proposal at this stage would be to use this RFC as a base and provide
an extension to it. Something along the lines of:
* Add a new conditional request 'if-block-match' which would have our block
hashes
* Investigate if any of the defined encodings they use are useful, and use
one if they are, or use our existing encoding.
* Use the 226 response type to resolve the caching intermediate proxy
problem.
* Use implied field contents for the accepts-instance manipulation fields
specified in the delta encoding RFC to reduce header size.

I will try get a doc committed to git in the next couple of weeks,
unfortunately I am also migrating from New Zealand to Belgium in this period
so may not be able to put many hours in, will see how it goes.

Toby

2009/4/6 <tridge at samba.org>

> Hi Toby,
>
>  > This is transmitted in two forms. One is an SHA1 hash of the complete
> chached
>  > file, and the other is a set of block hashes.
> ...
>  > Content-Hash:
>  > This will be an sha1 hash of the entire cached body, and will allow the
> server
>  > to transmit deltas based on its knowledge of past versions of the page.
>
> How do you imagine that this hash would be used? I don't think it is
> practical to think that servers would keep a record of all the dynamic
> pages they have been served out, and for static pages I think the
> normal cache tag mechanisms already work well.
>
> I think a SHA1 or similar of the servers generated page is really
> worthwhile, but a whole file hash of what the client has in cache
> doesn't gain anything that I can see.
>
> btw, I also wonder if you've seen this:
>
>  http://www.ietf.org/rfc/rfc3229.txt
>
> That is the result of earlier efforts to standardise delta encoding in
> HTTP. I was a little bit involved in that effort, although it
> concentrated on storing old copies on the server, which I wasn't
> interested in.
>
> Still, it should provide some very useful background to the current
> effort.
>
> Cheers, Tridge
>



-- 
This email is intended for the addressee only and may contain privileged
and/or confidential information
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/http-crcsync/attachments/20090419/b3a80d40/attachment.htm 


More information about the Http-crcsync mailing list