- From: Richard Bradbury <richard.bradbury@rd.bbc.co.uk>
- Date: Thu, 28 Jul 2016 08:36:05 +0100
- To: ietf-http-wg@w3.org
- Message-ID: <9359853a-b1dd-2d3c-c71c-d66285bc95e7@rd.bbc.co.uk>
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
Attachments
- image/png attachment: blind-proxy-cache-sequence_2016-07-28.png
Received on Thursday, 28 July 2016 07:36:43 UTC