Re: HTTP/2 vs. proxies ?

I know a lot of organisations that will just block anything they cannot 
control.

So to consider it viable that there be no room for forward proxies in 
the internet of the future is a position that is not particularly 
well-connected with reality.

All the move to TLS did was promote the deployment of MiTM, and slow 
things down quite a bit.


------ Original Message ------
From: "bizzbyster@gmail.com" <bizzbyster@gmail.com>
To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 24/06/2014 9:33:42 a.m.
Subject: Re: HTTP/2 vs. proxies ?

>For encrypted traffic, forward proxies are functionally bypassed and 
>most HTTP/2 traffic will be encrypted. When they do see the rare 
>plaintext attempt to upgrade to HTTP/2, proxies can simply strip the 
>header and prevent it. Therefore proxies have little motivation to 
>implement it. HTTP/2 with mandatory TLS (the Google and Mozilla 
>position) is an attempt to obsolete forward proxies, which explains why 
>lack of proxy support in HTTP/2.0 is not a blocking issue to go to last 
>call.
>
>Thanks,
>
>Peter
>
>On Jun 21, 2014, at 12:52 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> 
>wrote:
>
>>  In message 
>><CABkgnnX9+sf=1RmgyK498ZQwDX+tbAVinck4wpzUgTt4RyH4Cw@mail.gmail.com>
>>  , Martin Thomson writes:
>>
>>>  We killed it so that we could avoid having to talk about it any 
>>>more.
>>>  That worked out well, didn't it?
>>
>>  I'm increasingly getting the feeling that we have people who like
>>  the HTTP/2.0 draft and people who work with proxies, and that those
>>  two sets are almost exclusive ?
>>
>>  I would be interesting to see what a straw-poll of these two
>>  questions would show:
>>
>>  A) I think HTTP/2.0 is ready for last call YES/NO
>>
>>  B) My primary HTTP/2.0 interest is proxy technology YES/NO
>>
>>  --
>>  Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>>  phk@FreeBSD.ORG | TCP/IP since RFC 956
>>  FreeBSD committer | BSD since 4.3-tahoe
>>  Never attribute to malice what can adequately be explained by 
>>incompetence.
>>
>
>

Received on Monday, 23 June 2014 22:40:26 UTC