Hacker News Reader

Comment by pierrebai | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com