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.

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

   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:00:24 UTC