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

HTTP/2.0 Initial Draft Released

apiux.com

Post reply on HN
Print view View original

31–35 of 35 posts

Re: HTTP/2.0 Initial Draft Released

#31

Post by jimktrains2 »

agentS wrote: post #29
jimktrains2 wrote: post #16

I think that the changes being made for "HTTP 2" are a terrible decision for HTTP. For SPDY, sure, make it as complex and as hard to work with as you want in the name of performance, but please keep my HTTP a nice, simple, text-based protocol that I can work with very easily. I just feel that HTTP should not reïmplement TCP. SPDY/HTTP2 just seems much more complex than necessary. http://jimkeener.com/posts/http is a…

That post both advocates for TLS-everywhere (which I support) and thinks it would be beneficial to drop HTTP Keep-Alive... Aren't you concerned about the latency hit? TCP has 1 RTT to setup, TLS has 1+ RTT to setup. Also, TCP's congestion window grows over time; with your proposed model, you'd continuously open connections with tiny congestion windows, rather than a few connections with growing congestion windows. I…

I understand why Keep-Alive exists, but I think HTTP is just the wrong place. I don't believe that the round-trip latency shouldn't be an issue. It simply creates too much complexity for what is suppose to be a simple protocol.

> I think all it'd take to change your mind is to load Facebook or Twitter with SPDY and Keep Alives turned off...

I also believe that those sites are loading way too many resources. I'm also not against SPDY, but I don't think it should be HTTP. If someone wants to use SPDY, then so be it.

EDIT: Actually, I just loaded Twitter and Facebook with HTTP 1.0 (No Keep Alive). It was a bit slower, on the order of a handful of seconds, but nothing that I would consider terrible. These are also some of the heaviest sites a browser is going to load.

Re: HTTP/2.0 Initial Draft Released

#32

Post by chacham15 »

jimktrains2 wrote: post #30
chacham15 wrote: post #28

Earlier quoted context omitted.

I actually dont like a lot of what is on that page. For example: he says to remove the User-Agent header. Without that https://www.dropbox.com/downloading wouldnt work (where they can give you the correct download and show you pictures of how to access/install it). Furthermore, the Date header is very successfully used for caching operations in many cases. Moreover, it suggests problems that I see (such as the cookie…

> For example: he says to remove the User-Agent header. Without that https://www.dropbox.com/downloading wouldnt work (where they can give you the correct download and show you pictures of how to access/install it). There is no good reason to do UA sniffing. That page could simply provide you one of 3 (or more) options to select. > Furthermore, the Date header is very successfully used for caching operations in many…

> There is no good reason to do UA sniffing. That page could simply provide you one of 3 (or more) options to select.

So, giving people the correct file instead of making them know what they need (which many people dont... especially if it is browser specific) is not a good reason? What if a server wants to provide a client with native order endianess (for RPC for example), that shouldnt be allowed?

> Date headers are not useful for that purpose. Expiration would be based on the time of the UA, not the one given by a server.

Tell that to my browser which countless times doesnt fetch a new file because it has a cached copy. Furthermore, if the headers are stored with the cached copy, there is no server/client time problem because you can calculate the difference between server time and client time.

> The session should be ephemeral and not matter anyway, so there is no reason for it to be signed.

This is correct in idea, but not in practice. Often times, the server isnt a single server, but rather a set of load-balanced servers. When this happens, it is hard to keep track of client state because a client might get load-balanced to another machine on its next request. Therefore, client state is kept with the client (and signed to make sure that it is legitimate). This sort of behavior has become necessary, although can be better dealt with with some sort of standard (esp. to ensure the protection of the cookie et cetera).

Re: HTTP/2.0 Initial Draft Released

#33

Post by jimktrains2 »

chacham15 wrote: post #32
jimktrains2 wrote: post #30

Earlier quoted context omitted.

> For example: he says to remove the User-Agent header. Without that https://www.dropbox.com/downloading wouldnt work (where they can give you the correct download and show you pictures of how to access/install it). There is no good reason to do UA sniffing. That page could simply provide you one of 3 (or more) options to select. > Furthermore, the Date header is very successfully used for caching operations in many…

> There is no good reason to do UA sniffing. That page could simply provide you one of 3 (or more) options to select. So, giving people the correct file instead of making them know what they need (which many people dont... especially if it is browser specific) is not a good reason? What if a server wants to provide a client with native order endianess (for RPC for example), that shouldnt be allowed? > Date headers ar…

> So, giving people the correct file instead of making them know what they need (which many people dont... especially if it is browser specific) is not a good reason?

No, it is not. Give the user the option of what to download. What if I want the Windows version even though I'm running Linux?

> What if a server wants to provide a client with native order endianess (for RPC for example), that shouldnt be allowed?

RPC should have a standard byte order defined.

> Tell that to my browser which countless times doesnt fetch a new file because it has a cached copy.

That's based on cache control, which isn't affected by the Date header sent by the server.

> Often times, the server isnt a single server, but rather a set of load-balanced servers.

I know. I've set these systems up before. There shouldn't be anything of consequence stored on the client. So what if someone changes the session ID? Does it really matter? If someone has someone else's ID they probably have the signature too. If it's a random search, using random ids goes a very long way. Also, beyond sessions, there doesn't need to be a session. There are now ways to store data on the client that don't require sending it back and forth to the server on every request.

Re: HTTP/2.0 Initial Draft Released

#34

Post by gsnedders »

X4 wrote: post #25
digitalsushi wrote: post #20

Earlier quoted context omitted.

What is so difficult about encrypting HTTP with an SSL Layer? SSL is a key you keep and an unlocked padlock you give someone. They use it to give back a box with no idea how to open it. You configure a web server with a key and a padlock. It keeps the key and serves the padlock. How can this be improved? (Serious question, maybe it can - this concept still seems esoteric to many)

SSL has the concept of many central authority organs (many of them got compromised or hand their private keys to government agencies), there is the proposal of a web-of-trust to counter that, but it's not there yet. Hmm, do you suggest a new protcol/idea/improvement? A TCP/IP alternative also needs a security layer (not necessarily SSL though). No offense, but if it's so easy, then you may know something many scienti…

Replacing SSL/TLS just because of the current CA system is absurd. Nothing in either requires CAs (indeed, in theory anyone can issue a root certificate, and that's very much a feature). The issue is how to convey what certificates are legimite and which are not, and that's a tangential issue to whether you allow trusted subtrees or not.

Re: HTTP/2.0 Initial Draft Released

#35

Post by inopinatus »

hobohacker wrote: post #11
inopinatus wrote: post #6

Why didn't they use SRV[1] records in DNS to resolve http2 requests? It has so many advantages: * Permitted at the domain apex (yes really! unlike CNAMEs!) * Allow weighted round-robin * Allows lower-priority fallback services * Unusual port numbers no longer required in URIs * Doesn't get confused with non-HTTP services located at the same FQDN. It's the modern way to federate services! And there's very wide DNS ser…

https://code.google.com/p/chromium/issues/detail?id=22423 discusses some of the issues with using SRV records in browsers. SRV records could help clients discover server HTTP/2 support, but it does not mean that all intermediaries along the path support it.

Kinda moot; that thread is a discussion of what happens if it isn't explicitly in the standard.
Post reply on HN