Re: Moving forward with HTTP/2.0: proposed charter

On 09.08.2012 15:22, Adrien W. de Croy wrote:
> 
> ------ 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 :)
>

Urrr.

> 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.

305 sounds fine until you get to that "single request" statement.

Other requests for even other files on the same server are not to be 
fetched from the proxy by default. I don't really see the usefulness for 
that limitation. Ootherwise as you say its just a server negotiating use 
of a proxy, the browser is free to do whatever it needs in the way of 
security or alternatives.

The big stickler is that to operate, it does require an MITM. Which is 
a bit like mandating MITM in an IETF document.

An ICMP rejection code or some such which can be trivially sent by 
firewalls on the TCP SYN without MITM of the HTTP layer would be a much 
better implementation for this type of bounce. It would also work for 
both HTTP and HTTPS without breaking either ones security model.

Amos

Received on Thursday, 9 August 2012 03:53:13 UTC