Alex and I had a good discussion around the open issues remaining in defining this specification and in implementing the apache module incarnation of it. I will try summarise the discussion below.<br><br>To enable clients to keep their request size below ~2500 bytes we should allow the client to configure how many hashes that send. Specificed as a power of 2 as the first character of the hash string.<br>
<br>We will use a 60 bit hash size unless emperical testing indicates otherwise.<br><br>We will add an optional response header that includes a mod rewrite style regex as a hint to the client as to other files they could use this response as a base for.<br>
<br>We need to reapply any content encodings the server sent. To do this we must manipulate the accept-encodings header to make sure that the &#39;client&#39; proxy does not get any encodings it cant reapply, and the &#39;server&#39; proxy anything it cannot decode.<br>
<br>We will not delta code at all for http 1.0 clients as we cannot indicate an error correctly to them, this of course is an implementation detail. The client proxy could reassemble the full content before sending it to the 1.0 client, but that could be quite resource intensive.<br>
<br>We will send a string hash of the full page as a special block in the encoded response.<br><br>The origin headers will be sent as the first block of the response, allowing us to compress them.<br><br>We need to specify the crc polynomial used in the standard document.<br>
<br>In terms of the current implementation, in addition to the above we need to optimise how we send stream flushes and also how we cache. We should probably implement our own caching and drop the dependency on the apache mod cache code as we have different goals.<br>
<br>Also once we have merged the above changes into the protocol document we need to start reworking it to be suitable for circulating as an RFC, and hopefully begin the process of making it an official standard...<br><br>
Toby<br>