undefined | Better HN

0 pointsphkamp12y ago0 comments

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.

0 comments

11 comments · 4 top-level

pierrebai12y ago· 3 in thread

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

ubernostrum12y ago

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

phkampOP12y ago

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.

Sammi12y ago

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?

1 more reply

youngtaff12y ago· 3 in thread

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

phkampOP12y ago

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.

youngtaff12y ago

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?

1 more reply

dfabulich12y ago

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

throwaway776712y ago· 1 in thread

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

phkampOP12y ago

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.

Titanous12y ago

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

j / k navigate · click thread line to collapse

0 comments

11 comments · 4 top-level

pierrebai12y ago· 3 in thread

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

(The same argument hold to SCTP vs TCP.)

ubernostrum12y ago

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

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

phkampOP12y ago

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

Sammi12y ago

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

1 more reply

youngtaff12y ago· 3 in thread

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

phkampOP12y ago

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.

youngtaff12y ago

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?

1 more reply

dfabulich12y ago

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

throwaway776712y ago· 1 in thread

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

phkampOP12y ago

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.

Titanous12y ago

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

j / k navigate · click thread line to collapse