On 15/12/2011 7:38 p.m., Willy Tarreau wrote:
> Hi Mark,
>
> On Thu, Dec 15, 2011 at 01:01:36PM +1100, Mark Nottingham wrote:
>> We're not quite ready for Working Group Last Call, but I do believe it's not far off. So, if you have issues to bring to the Working Group, please do so soon.
> Mid-April, we had a discussion with Adrien the suggestion of making UAs
> connect to proxies using https instead of http so that we stop the horrors
> that are currently performed for authentication in many corporate environments
> (you know, redirect to https for auth + set-cookie for the target domain +
> redirect again + failure quite often...), and apparently there was no ticket
> for this.
>
> Adrien even suggested the use of "GET https://" instead of CONNECT in
> some cases so that filtering proxies can safely inspect the contents.
>
> Since corporate proxies are a place where HTTP works very badly, I think
> we should address these issues before the final release.
>
> Best regards,
> Willy
>
>
I'm wavering between "please, please, please!", and "What can HTTPbis do
about it?".
In Squid we have supported SSL/TLS negotiation on incoming sockets for
some years now. 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.
So what can HTTPbis do beyond what is already done in part 1 section 2.7.2 ?
I do take exception to the sentence which erases server admins choice
over the public/private nature of secured resources:
"
Unlike the "http" scheme, responses to "https" identified requests
are never "public" and thus MUST NOT be reused for shared caching.
"
IMHO, "Cache-Control: public" should be permitted to enable shared
caching on resources, matching how it works on authenticated resources
and any other default-private response in http://.
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.
This opens the door for shared caches to optimize high-bandwidth
resources like images which are deemed by their sites to be non-secure
but must be served within https:// due to security considerations about
cross-scheme problems.
AYJ