Re: Getting to Last Call

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

Received on Thursday, 15 December 2011 07:43:03 UTC