W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: 2 questions

From: Cory Benfield <cory@lukasa.co.uk>
Date: Mon, 30 Mar 2015 09:26:27 +0100
Message-ID: <CAH_hAJHreb974bdJY7UEgdf4E2QOKNNtqHE2aXC7Snx3wRNjew@mail.gmail.com>
To: Adrien de Croy <adrien@qbik.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>, Glen <glen.84@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 30 March 2015 at 04:15, Adrien de Croy <adrien@qbik.com> 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.

In this case I think Google and Firefox are probably right: HTTP/2 in
plaintext is likely to break frequently and mysteriously. 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. 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).

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.
Received on Monday, 30 March 2015 08:27:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:43 UTC