Re: 2 questions

On 30/03/2015 9:26 p.m., Cory Benfield wrote:
> On 30 March 2015 at 04:15, Adrien de Croy wrote:
>>
>> I can buy that 1/3 of web requests use TLS.
>>
>> however that does not apply to 1/3 of web sites using TLS.  Probably just FB
>> and google alone account for 1/3 of web requests.
>>
>> There are surely hundreds of millions of sites.  That's at least tens of
>> millions of administrators who will need to take on the burden of making TLS
>> work on their site.  Many will not see any point in this.  Pretty much all
>> the sites that felt a need to deploy TLS will have already done so, and the
>> others will not thank the IETF or google or the chromium project for
>> attempting to force costs on them.
> 
> No-one is being *forced* to do anything. HTTP/1.1 is not going away.
> If you dig back through the archives of this working group you'll
> repeatedly find statements from almost all camps that HTTP/1.1 will be
> around for the foreseeable future. Website owners that cannot set up
> TLS will still find plenty of support for plaintext HTTP.

So your answer is "Just use HTTP/1.1" ?

Regardless of how long the transition would take one of the goals of
HTTP/2 is to replace it. *Any* network which is forced to stay with
HTTP/1 simply because of a missing protocol capability is a failure of
HTTP/2.

> 
> In this case I think Google and Firefox are probably right: HTTP/2 in
> plaintext is likely to break frequently and mysteriously.

Guesses and supposition. Look at who you are throwing those arguments at
... the very authors of the major middleware implementations.

The Chrome choice was based on SPDY metrics IIRC. Which measured how
many connections over TLS were force to "just use HTTP/1.1" versus
allowed to use SPDY. That was done under conditions where *none* of the
middleware supported SPDY and TLS was able to supply a bypass.

Neither of those measurement conditions are true for HTTP/2. We major
middleware implementations authors participate in the WG and are
actively implementing HTTP/2 already. The growth of TLS interception
will undoubtedly have reduced TLS ability to bypass middleware.


The middlware argument for TLS is a red herring.


> This is
> mostly because of intermediaries that believe they understand HTTP,
> but don't do it very well (HAProxy is a good example I can think off
> of the top of my head). These intermediaries are usually transparent
> to HTTP/1.1 users, but they will likely break HTTP/2 traffic over port
> 80.

Those of us participating in the WG have already ensured that our
software, even legacy installs, interoperates properly with HTTP/2 to
trigger HTTP/1.1 fallback cleanly during the transition. The HTTP/2
protocol is also a lot more strict syntactically so many mistakes and
problems are simply no longer possible once the software is upgraded.


> Chrome and Firefox are therefore acting in the interest of both
> users and operators when they forbid this kind of traffic. They're
> saving your users from thinking your website is broken because their
> ISP deployed some terrible intermediate 'service' that mangles HTTP/2
> (consider Comcast's injection of HTTP headers, for example).

Injection of headers is compliant with HTTP (both versions).

One can as easily point at the many millions of users forced to endure
horrible network lag issues and sometimes outright DoS when Chrome
implemented SDCH encoding.


Dont kid yourself about browsers protecting either users or websites -
at least no more than they need to make gains in the browser wars. We
have a loooong laundry list of things they refuse to do that would
vastly improve end users privacy, security, and website efficiency.
Their focus IME is towards their own corporate goals (as one should expect).

> 
> At this point in time, my HTTP/2 implementation does not support
> plaintext HTTP/2. I will add support for it in the next few weeks, but
> I do not expect it to work in the vast majority of cases, and will be
> emitting warning logs to that effect.
> 

Are you emitting similar warnings for all HTTP/2-over-TLS failures?
 You will find a lot of middleware out there these days decrypting the
TLS and demanding HTTP/1 inside. The magic PRI prefix "request" works
the same regardless of TLS usage - as it was designed to.

Amos

Received on Monday, 30 March 2015 09:28:05 UTC