Re: Moving forward on improving HTTP's security

On Wed, Nov 13, 2013 at 9:24 PM, Roberto Peon <grmocg@gmail.com> wrote:
> 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.

If that's the case, WebSocket is also "undeployable" since it tunnels
though port 80 as well.


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

Received on Thursday, 14 November 2013 17:14:17 UTC