Hacker News Reader

Comment by acdha | Hacker News Reader

For those of us who don't follow this discussion in detail, why are you thinking the protocol needs to be scrapped outright rather than modified? Is it simply the complexity Greg Wilkins mentioned or are you really thinking about bigger philosophical changes like dropping cookies as we know them? Dropping HPACK seems like a great engineering call but that seems like a relatively minor change rather than starting over.

http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... made me wonder what your standby plan would be – let the people who really need to care about performance use SPDY until a more ambitious HTTP 2.0 stabilizes? One of the concerns I have is that many people want performance now and it seems like HTTP 2.0 might turn into the next XHTML if it takes too long to emerge.

View on HN

I think the fundamental problem with HTTP/2.0 is that it is a inadequate rush job for no good reason.

If you really want to gain performance for instance, the way to go is to get rid of the enormous overhead of cookies, to replace the verbose but almost content-free User-Agent header and so on.

Likewise, wrapping all the small blue 'f' icons and their associated tracking icons in TLS/SSL does not improve privacy on the net in any meaningful way.

But the entire focus has been to rush out a gold-plated version of SPDY, rather than to actually solve these "deep" problems in HTTP.

Similarly: Rather than accept that getting firewalls fixed will take a bit of time, everything gets tunneled through port 80/443, with all the interop trouble that will cause.

And instead working with the SCTP people on getting a better transport protocol than TCP ? Stick it all into the HTTP protocol.

Nobody seems to have heard the expression "Festina Lente" in this WG.

If I understand your argument correctly, you are opposed to oppurtunistic encryption as there is no identity validation, as it does not improve privacy.

But an active man-in-the-middle attack at least has a chance of being detected, as opposed to the current passive sniffing being done on a wholesale basis. Do you not see any value in that?

(I have not followed the HTTP/2 development closely enough to comment on other areas of concern.)

You read me wrong then.

I'm opposed to a protocol which claims to "improve privacy" while leaving some of the most troubling privacy invasions in place.

If we are going to the trouble to upgrade HTTP, we fix all the serious problems we can.

All these concerns share an overlook of the practicalities of the web.

On the protocol level, there is a huge knowledge and API momentum that makes any protocol that fundamentally differs from HTTP an uphill battle for adoption. Whatever changes are made to HTTP, if it is too different from the application POV, it will linger behind.

Same thing about tunneling. It may not be elegant, but it's the way to fight the system. You won't change IT behaviour with a protocol change. One possible way to work would be to make new version oF HTTP have a working mode that reduces overhead to a minimum for any tunneling operation.

(The same argument hold to SCTP vs TCP.)

* All these concerns share an overlook of the practicalities of the web.*

There's nothing "practical" about HTTP/2.0. I've read the spec, since I was interested in it, and it confused the hell out of me. Then I learned that even people who implement networking specs for a living, and have tons of experience at it, are stuck trying to figure out how to implement the current spec.

So if you're going to push for shitty-but-practical, at least make sure you have the practical bit.

A well designed HTTP/2.0 would not "fundamentally differ from HTTP", and it would be trivial for web-servers like NGNIX and APACHE or frameworks like PHP to mask the differences for the application code.

For instance moving cookies to the server side would just require a simple key-value store lookup.

Forgive me if I'm not well enough informed to partake productively in this discussion. I just wanted to ask:

Can't anyone implementing a webclient and webservice on top of common web servers and browsers, choose to forgo cookies and keep the state server side? If this is so, then why do people choose to use cookies if they give more overhead?

Also you would need to keep some sort of unique identifier on the client, that the client can send the server, in order for the server to be able to look up the session state (a session id). Isn't this what cookies often are used for? I'm guessing this is probably what you meant "information-free session nonces" would solve above. This sounds interesting, could you explain this scheme to me or maybe point me in the direction of a good resource?

They could if the client provided a session-id so they knew which "cookie" to retrive from server-side storage.

My proposals is to do that, and have the top bit in the session-id mean "Persistent" or "Anonymous", so that client undisputably controls if anything will be stored about the session.

A Pesistent session-ID would be the same next time you visit the site, an Anonymous would be random, and thus not retrive any state on the server side, even if they saved it last time.

This would put the privacy decision in the hands of the client, provided we also eliminate crap like almost-per-user-unique user-agent headers.

Can't the client side do this already (with HTTP/1.1) by turning off cookies?

Or are you pushing for browsers to turn off cookies by default?

> Likewise, wrapping all the small blue 'f' icons and their associated tracking icons in TLS/SSL does not improve privacy on the net in any meaningful way.

It absolutely does, global passive attackers have been documented using the associated unencrypted tracking cookies to find targets.

> If you really want to gain performance for instance, the way to go is to get rid of the enormous overhead of cookies, to replace the verbose but almost content-free User-Agent header and so on.

Yes, they add request and response overhead but what evidence is there that removing them would deliver greater performance improvements than a multiplexed protocol does?

Comparing to multiplexing is wrong. You should compare it to the header-compression ("HPACK") which is a major complication and risk in HTTP/2.0

The answer is that well-designed cookies are incompressible because they come out of cryptographic algorithms.

Also, cookies are wrong, because they store the servers state on the client computer, which led the EU to legislate against them.

Using information-free session nonces would have neither of these problems, and take up much less bandwidth.

I understand the issue of complexity in header compression but the impression I get is you seem to object to the whole basis of HTTP/2 seemingly because it's not ambitious enough.

If it didn't have HPACK but still did multiplexing would you still say abandon it?

It's a tradeoff: The added complexity must provide sufficient benefit to be worth it. HTTP/2.0 doesn't IMO, not even close.

> Also, cookies are wrong, because they store the servers state on the client computer, which led the EU to legislate against them.

Can you spell this out in more detail? (Maybe you've written an article about this at some point?)

When, if ever, is it OK to store state on the client? It seems like you'd at least make an exception for one session ID. I presume you'd also make exceptions for client-side caches? Anything else?

Do you advocate against all forms of client-side storage? IndexedDB, localStorage, Web SQL, etc?

RESTful advocates keep telling me not to store state on the server. Do you agree with that? If I can't store state on the server and I can't store it on the client, where am I supposed to store it?

Reply on news.ycombinator.com