W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: Getting to Last Call

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 15 Dec 2011 09:04:11 +0100
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
Message-ID: <20111215080411.GC4614@1wt.eu>
Hi Amos,

On Thu, Dec 15, 2011 at 08:42:21PM +1300, Amos Jeffries wrote:
> I'm wavering between "please, please, please!", and "What can HTTPbis do 
> about it?".

Simply suggest that proxies SHOULD support it and that UAs SHOULD use it.

> In Squid we have supported SSL/TLS negotiation on incoming sockets for 
> some years now.

Glad to know, but we're still waiting for UAs to use it !

> For us it is simply a matter of the UA adding TLS on its 
> connections. AFAIK, only two UA have implemented it in all these years.

I've not even identified them :-(

> So what can HTTPbis do beyond what is already done in part 1 section 2.7.2 ?

Encourage its use by default ?

Also, decide whether proxies should perform https request on behalf of UAs
when they emit "https://" proxy requests. This would :
  - permit proxies to filter inappropriate requests (important in schools
    where you don't want you kids to visit adult sites)
  - make it possible to disable use of the CONNECT method which right
    now is a big security issue (I'm even regularly using it to SSH outside)
  - make it possible for content filtering proxies to filter responses
  - all of this without emitting fake certificates.

(...)
> Better wording would perhapse be:
> 
>   Unlike the "http" scheme, responses to "https" identified requests
>   default to "private" and thus MUST NOT be reused for shared caching
>   unless the "public" cache control is sent to indicate otherwise.

I agree this would help a lot !

Best regards,
Willy
Received on Thursday, 15 December 2011 08:11:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:51 GMT