Re: Moving forward with HTTP/2.0: proposed charter


------ Original Message ------
From: "Amos Jeffries" <squid3@treenet.co.nz>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 9/08/2012 2:59:54 p.m.
Subject: Re: Moving forward with HTTP/2.0: proposed charter
>On 09.08.2012 10:19, David Morris wrote: 
>>On Wed, 8 Aug 2012, Salvatore Loreto wrote: 
>>
>>>* define a 2.0 mechanism for advising clients of the proxy to use 
>>
>
>+1. 

+1
>
>
>>I see this as a system configuration issue and not really a problem 
>>to be solved by the HTTP working group. It is very much a chicken/egg 
>>problem. 
>>
>>Beyond that, this problem is nearly solved for iPhones with the 
>>provision 
>>for defining a proxy in APNs. VPN mobile configs also provide for 
>>definition of a proxy. I don't know other devices, but APNs look 
>>like they might be a general solution which transcend the iPhone. 
>
>
>Right now we have the usual industry-driven mess of a half dozen *not 
>quite working* semi-proprietary methods. Admin wanting to setup an 
>explicit proxy have to implement most of them. Client developers 
>wanting to add proxy support have to implement most of them - just in 
>case. And few people can really be bothered with that much work. 
>
>The APN method you point at being specific to iPhones makes it yet 
>another vendor-specific variant to implement alongside UNIX 
>"http_proxy" environment setting, Windows Group Policy proxy settings, 
>WPAD DHCP lookup, WPAD DNS lookup, manual editing of config settings 
>for hundreds of apps per user machine ... "bugger it just MITM port 80 
>and be done". 

there's also UPnP :)

It's a mess.  From a proxy vendor POV, it's a bit of a nightmare.

However, most discovery mechanisms don't use HTTP, at least not for 
everything.

However, if we had a new status code to indicate that intercepted 
connections were not permitted, then the client could go off and do 
discovery.

The response could even include a URL for a WPAD config script.

And before people suggest this opens huge holes to redirect people via 
nasty proxies over the internet...

well, any browser author that wrote code that blindly used a proxy they 
discovered through this method, without any sort of check to see if 
it's valid (e.g. should only be on their LAN), should be put up against 
the wall.

This is why I think the argument against 305, which caused it to be 
deprecated I think were a bit bogus.  They ignored the fact that the 
browser still gets to choose, and can do something a bit smarter.  Not 
that any client implemented 305 support though, but if it had been 
properly scoped out, I think it could have been more palatable, and 
therefore usable.

Adrien
>
>
>  See the problem there? 
>
>
>The WG needs to do something such as: 
>* picking up the WPAD draft and making it a proper standard, 
>* defining a standard SRV record, 
>* defining multi/broad-cast IP for proxies to listen on a port there, 
>* defining a standard proxy port (IANA registers a few dozen 
>proprietary ports) 
>* a _standard_ mix of the above? 
>* something else? 
>
>The key thing being that we end up with a simple standard way to do 
>it. When that happens we have one more axe to chip away at the MITM 
>desirability. 
>
>
>All fine and dandy using APN on cellular networks. So long as it works 
>dependably across device vendors, and the delivery of the details to 
>the application software also has a standard interface for developers 
>to use (libproxy is helping here but still not widely used). 
>
>Sure, we can't force everybody to follow the standard. But at least 
>there will be an agreed standard to work from and point at when things 
>go wrong. 
>
>Amos 
>
>

Received on Thursday, 9 August 2012 03:22:40 UTC