Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why HTTP/2.0 does not seem interesting (2012)

varnish-cache.org

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Why HTTP/2.0 does not seem interesting (2012)

#21

Post by yalogin »

jimktrains2 wrote: post #16
Qantourisc wrote: post #12

Earlier quoted context omitted.

Cookies with an expire of session and secure flag set: yes. But this should be more secure, and stored for 1 session implicitly.

And in theory less data, right? a session ID doesn't need to store the kilobytes that cookies do.

Why can't there be multiple sessions for different functionalities? I am not sure people are going to relinquish the cookie concept. All the sessions are doing is have the "cookies" transported as part of the HTTP message and not as a separate file (payload)

Re: Why HTTP/2.0 does not seem interesting (2012)

#22

Post by jokoon »

Well transmitting text never seemed really very much interesting.

http was nice because it was easy for software programmers to write apps that could work over http, because no binary protocol was involved: reading ASCII strings is never complicated. It was good for a growing industry.

Now most browsers are open source, why can't the IETF work out a binary protocol ? Bittorrent is binary, and it's awesome and it's used. Why can't any browser work out a binary protocol ? Truly dynamic pages over the network ? Why not ? I'm sure some software already does that. Make one open source, make it work on firefox or chrome, I guess things would start to light up.

Re: Why HTTP/2.0 does not seem interesting (2012)

#24

Post by tracker1 »

In reading this a protocol that supports two initial statements upon connection/negotiation as follows...

    s: http/2.0 {SERVER INFO}
    c: connect host/
after a session is started, the client may make other requests

    s: http/2.0 {SERVER INFO}
    c: connect host/{path}
    s: OK {server-cert/key} or DENIED ### Reason
    -- all futher requests encrypted against public key/cert
    c: session-join {SESSION_ID} {client key/cert}
    s: OK or DENIED...
    c: {COMMAND} {path}
from there, the "session_id" can be a key for server-side value storage/lookup, etc... sent over the encrypted channel

Re: Why HTTP/2.0 does not seem interesting (2012)

#25

Post by jimktrains2 »

yalogin wrote: post #21
jimktrains2 wrote: post #16

Earlier quoted context omitted.

And in theory less data, right? a session ID doesn't need to store the kilobytes that cookies do.

Why can't there be multiple sessions for different functionalities? I am not sure people are going to relinquish the cookie concept. All the sessions are doing is have the "cookies" transported as part of the HTTP message and not as a separate file (payload)

I'm not sure I understand you.

I'm talking about a Session-ID header that'd have a 128bit (say) max length or something. Not something that has a few kb limit like a cookie.

Also, a GET request wouldn't send a payload so I'm not sure what you mean.

Re: Why HTTP/2.0 does not seem interesting (2012)

#26

Post by emmett »

drostie wrote: post #17
yahelc wrote: post #4

Earlier quoted context omitted.

> Cookies are...freaking annoying here in Europe as you cannot visit a site anymore without being warned you are about to receive yet even more cookies. Seems like the blame for that lies not with cookies themselves, but with the EU's cookie law.

At best that's a symptom. Cookies are for session management; the central problem with cookies is that people feel that servers will treat certain sessions as ephemeral, but instead those servers track these people for a long-term creepy analysis. One connected problem is that many sites require cookies in order to show public content . Public-content sessions should be entirely ephemeral, meaning that you shouldn't…

For advertisers this is a non-starter, because it prevents you from knowing the size of your audience. All sites would immediately begin requiring some form of "login" in your scenario in order to enable tracking again.

If you can't track uniques, you can't sell ads, and that's pretty much all there is to it. So there's huge incentive to undermine any scheme to prevent unique user tracking.

The solution is to somehow ban advertising, but that's biting off a bit more than simple user privacy.

Re: Why HTTP/2.0 does not seem interesting (2012)

#27

Post by anonymfus »

emmett wrote: post #26
drostie wrote: post #17

Earlier quoted context omitted.

At best that's a symptom. Cookies are for session management; the central problem with cookies is that people feel that servers will treat certain sessions as ephemeral, but instead those servers track these people for a long-term creepy analysis. One connected problem is that many sites require cookies in order to show public content . Public-content sessions should be entirely ephemeral, meaning that you shouldn't…

For advertisers this is a non-starter, because it prevents you from knowing the size of your audience. All sites would immediately begin requiring some form of "login" in your scenario in order to enable tracking again. If you can't track uniques, you can't sell ads, and that's pretty much all there is to it. So there's huge incentive to undermine any scheme to prevent unique user tracking. The solution is to somehow…

To sell ads you don't need to show exact size of audience, estimation is enough as proven by TV.

Re: Why HTTP/2.0 does not seem interesting (2012)

#28

Post by jessaustin »

exceptione wrote: post #3

In my view, HTTP/2.0 should kill Cookies as a concept, and replace it with a session/identity facility, which makes it easier to do things right with HTTP/2.0 than with HTTP/1.1. count me in. Cookies are a huge waste of bandwidth and freaking annoying here in Europe as you cannot visit a site anymore without being warned you are about to receive yet even more cookies.

I always thought that rfc2616 felt more "pure" since it didn't mention cookies. I mean, http was supposed to be stateless right?

Re: Why HTTP/2.0 does not seem interesting (2012)

#29

Post by jessaustin »

richardwhiuk wrote: post #19

What really frustrates me about HTTP as a protocol is that it provides the beginning of a framework to do session management using the WWW-Authenticate headers, but it's ignored because the site can't provide a good UX. Instead we end up with phishing, terrible login forms and poor security when people reimplement session management in Cookies.

I've long wondered if we might have had better alternatives via WWW-Authenticate if major browsers had made it straightforward/possible to write auth plugins. (Actually it probably is possible, but AFAICT not without non-portable munging about in NPAPI.) If Mozilla actually do something to integrate Persona into their clients, will they do so in an open, repeatable way (with an API accessible to extensions) or will it just be more of the same oddball one-off coding that supported NTLM?

Re: Why HTTP/2.0 does not seem interesting (2012)

#30

Post by rlanday »

anonymfus wrote: post #27
emmett wrote: post #26

Earlier quoted context omitted.

For advertisers this is a non-starter, because it prevents you from knowing the size of your audience. All sites would immediately begin requiring some form of "login" in your scenario in order to enable tracking again. If you can't track uniques, you can't sell ads, and that's pretty much all there is to it. So there's huge incentive to undermine any scheme to prevent unique user tracking. The solution is to somehow…

To sell ads you don't need to show exact size of audience, estimation is enough as proven by TV.

If you’re an Internet company trying to pull advertising dollars away from TV, one of your arguments is that you can do much better tracking. When you run a TV ad, everyone watching the show gets the same ad, and people watching different shows see the same ad a non-optimal number of times.
Post reply on HN