Having finally got a chance to read the RFC last weekend it raises a few interesting points.<br>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<br>
2) There are interesting points raised about caching proxies<br>3) There are some ideas included in the RFC around hinting to caches how long they should keep data around.<br><br>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.<br>
<br>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:<br>* Add a new conditional request 'if-block-match' which would have our block hashes<br>
* Investigate if any of the defined encodings they use are useful, and use one if they are, or use our existing encoding.<br>* Use the 226 response type to resolve the caching intermediate proxy problem.<br>* Use implied field contents for the accepts-instance manipulation fields specified in the delta encoding RFC to reduce header size.<br>
<br>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.<br><br>Toby<br>
<br><div class="gmail_quote">2009/4/6 <span dir="ltr"><<a href="mailto:tridge@samba.org">tridge@samba.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Toby,<br>
<br>
> This is transmitted in two forms. One is an SHA1 hash of the complete chached<br>
> file, and the other is a set of block hashes.<br>
...<br>
> Content-Hash:<br>
> This will be an sha1 hash of the entire cached body, and will allow the server<br>
> to transmit deltas based on its knowledge of past versions of the page.<br>
<br>
How do you imagine that this hash would be used? I don't think it is<br>
practical to think that servers would keep a record of all the dynamic<br>
pages they have been served out, and for static pages I think the<br>
normal cache tag mechanisms already work well.<br>
<br>
I think a SHA1 or similar of the servers generated page is really<br>
worthwhile, but a whole file hash of what the client has in cache<br>
doesn't gain anything that I can see.<br>
<br>
btw, I also wonder if you've seen this:<br>
<br>
<a href="http://www.ietf.org/rfc/rfc3229.txt" target="_blank">http://www.ietf.org/rfc/rfc3229.txt</a><br>
<br>
That is the result of earlier efforts to standardise delta encoding in<br>
HTTP. I was a little bit involved in that effort, although it<br>
concentrated on storing old copies on the server, which I wasn't<br>
interested in.<br>
<br>
Still, it should provide some very useful background to the current<br>
effort.<br>
<br>
Cheers, Tridge<br>
</blockquote></div><br><br clear="all"><br>-- <br>This email is intended for the addressee only and may contain privileged and/or confidential information<br>