Re: Informal meeting on blind caching

On 27/07/2016 13:49, Amos Jeffries wrote:
> On 27/07/2016 11:11 p.m., Martin Thomson wrote:
>> Yes you have correctly understood the draft.
>>
>> On 27 July 2016 at 12:33, Richard Bradbury wrote:
>>> Finally, a basic question: For this to work, both the origin server and the
>>> proxy server need to support blind caching. So how does a User Agent
>>> discover whether both do? Through trial and error?
>> We use Accept-Encoding and a new header field to signal to the origin
>> server that the client is willing to do this.  The proxy is explicitly
>> configured and this capability could be part of that configuration,
>> but we could do something better than that.  Trial and error might
>> work, but again, a better plan would be to have explicit signaling.
>> Off the cuff, /.well-known/ might work.
>>
> As would a BC reply header in the initial CONNECT tunnel reply message
> which is generated by the explicit proxy.

Ah yes... A simple and neat idea. The proxy could verify that the origin 
at the far end of the TLS tunnel also supports out-of-band encoding 
before returning that |BC| response header, thereby killing two birds 
with one stone.

I have added this additional pre-flight negotiation to the attached 
sequence. You'll see that I have included |BC| and |Accept-encoding| 
request headers in the initial |CONNECT|. Is this necessary to initiate 
the negotiation? Or should the response just include |BC| regardless?


Thanks both,

-- 
Richard Bradbury | Lead Research Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London  W12 7SB.
T: 0303 040 9672  F: 020 8811 8815