Re: Moving forward on improving HTTP's security

As far as I've seen, most small businesses get little enough traffic that
they wouldn't notice any difference w.r.t CPU usage.
.. and if it bothers them, they'd use HTTP/1.1 for web stuff, or are
already doing so.

In any case, it is extremely likely that HTTP/2.0 on port 80 is nearly
undeployable for the web today. There are too many MITM proxies out there
that expect port 80 to carry only a subset of HTTP/1.1, and make a mess of
anything else.

So, any web deployment of HTTP/2 that is going to be reliable WILL use
encryption, and WILL incur the cost of encryption.

.. as such, the only real question here is simply about authentication.

I do expect that we'll see HTTP/2.0 in the clear, but that would be inside
of a VPN or other private network, and Mark's original email was talking
about the web usecase.

-=R


On Wed, Nov 13, 2013 at 7:01 PM, Frédéric Kayser <f.kayser@free.fr> wrote:

> This also means HTTP/2 is not for everyone, it's only for big business,
> and you cannot get the speed benefit without some hardware investments.
> It also means that speed consciousness webdesigners will still have to
> continue using the awful CSS sprites trick when their target server is
> still HTTP/1.1 based.
> HTTP/2 sounded like a magical speed promise… that would be quickly
> adopted, but now it just looks like an alternative solely made for the big
> guys.
>
> Roberto Peon wrote:
>
> > The radio far dominates battery life considerations w.r.t IO on mobile
> devices, so if we were super worried about that, we'd be working on getting
> the best possible compression algorithm for entity-bodies.
> >
> > I note that with Mark's proposed 'C':
> > Encryption is not mandatory- one simply uses HTTP/1.1 if one don't want
> encryption. Noone is thus forced to do anything: they're not forced to
> spend more CPU, etc., unless they believe the benefit outweighs the cost.
> >
> > Honestly, this is where we are anyway. We don't have the power, even if
> we wished it, to throw away HTTP/1.X and so we'll always be competing
> against its cost/benefit.
> >
> > I'm pretty happy with either 'C' or any other proposal that provides
> strong downgrade protection.
> >
> > -=R
>
>
>