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

21–30 of 35 posts

Re: HTTP/2.0 Initial Draft Released

#21

Post by nly »

wmf wrote: post #19
X4 wrote: post #13

I think HTTP/2.0 should break backward compatibility and take a more advanced step than "little improvements like that". Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. The reason is that even adopting HTTP2.0 in that state would take at least a decade or more. Here's stuff that backs my argument:s a) ht…

QUIC (which may become TCP 2.0 for HTTP/3.0 to run over) sounds like what you're looking for.

QUIC lives on top of UDP. If we reinvent TCP on top of UDP we may as well just throw in the towel on IPv6 and embrace IPv4 + NAT. Why bother trying to fix layer 2 when we're content to fuck shit up on the higher layers for the sake of back compat? IPv6 is our chance to bring back end-to-end networking with stateless routers.

Re: HTTP/2.0 Initial Draft Released

#22

Post by X4 »

jimktrains2 wrote: post #17
X4 wrote: post #13

I think HTTP/2.0 should break backward compatibility and take a more advanced step than "little improvements like that". Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. The reason is that even adopting HTTP2.0 in that state would take at least a decade or more. Here's stuff that backs my argument:s a) ht…

> Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. You do realize HTTP and TCP/IP reside at very different OSI stack levels, right? Reïnventing TCP is not HTTP's job.

eh, yes.. now what? You do realize that the HTTP RFCs define what protcols are used?

I know that most TCP improvements mostly add new behaviour to specific situations, especially congestion and yes I have read those papers/links. I know that many improvements are UDP based. So, I think you misread it. I said kill TCP/IP in order to replace it by something better and wished that HTTP/2.0 would be that anticipated step. Did you even check the alternatives, before going negative?

Re: HTTP/2.0 Initial Draft Released

#23

Post by X4 »

qwerta wrote: post #15
X4 wrote: post #13

I think HTTP/2.0 should break backward compatibility and take a more advanced step than "little improvements like that". Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. The reason is that even adopting HTTP2.0 in that state would take at least a decade or more. Here's stuff that backs my argument:s a) ht…

>and take a more advanced step than Already done several times. Have look at UDP and its usages.

See the links in my post, did you check them? Most are UDP based.

Re: HTTP/2.0 Initial Draft Released

#24

Post by X4 »

ErsatzVerkehr wrote: post #14
X4 wrote: post #13

I think HTTP/2.0 should break backward compatibility and take a more advanced step than "little improvements like that". Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. The reason is that even adopting HTTP2.0 in that state would take at least a decade or more. Here's stuff that backs my argument:s a) ht…

> more efficiently compressed, more government resistant and more easily encryptable Protocol Probably these things should not all be done at the same layer.

indeed & I never said that.

Re: HTTP/2.0 Initial Draft Released

#25

Post by X4 »

digitalsushi wrote: post #20
X4 wrote: post #13

I think HTTP/2.0 should break backward compatibility and take a more advanced step than "little improvements like that". Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. The reason is that even adopting HTTP2.0 in that state would take at least a decade or more. Here's stuff that backs my argument:s a) ht…

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 scientists and researchers and cryptographers haven't discovered, in any case I'm happy and all ears, if you are willing to contribute to a solution.. http://en.wikipedia.org/wiki/Secure_Socket_Layer

Re: HTTP/2.0 Initial Draft Released

#26

Post by wmf »

nly wrote: post #21
wmf wrote: post #19

Earlier quoted context omitted.

QUIC (which may become TCP 2.0 for HTTP/3.0 to run over) sounds like what you're looking for.

QUIC lives on top of UDP. If we reinvent TCP on top of UDP we may as well just throw in the towel on IPv6 and embrace IPv4 + NAT. Why bother trying to fix layer 2 when we're content to fuck shit up on the higher layers for the sake of back compat? IPv6 is our chance to bring back end-to-end networking with stateless routers.

QUIC is the prototype; if you build an experiment that doesn't work in the short term then you never learn from it and you can't fix the flaws you didn't learn about. Once it's finished maybe it could become a real protocol instead of layered on UDP.

Re: HTTP/2.0 Initial Draft Released

#27

Post by jimktrains2 »

X4 wrote: post #22
jimktrains2 wrote: post #17

Earlier quoted context omitted.

> Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. You do realize HTTP and TCP/IP reside at very different OSI stack levels, right? Reïnventing TCP is not HTTP's job.

eh, yes.. now what? You do realize that the HTTP RFCs define what protcols are used? I know that most TCP improvements mostly add new behaviour to specific situations, especially congestion and yes I have read those papers/links. I know that many improvements are UDP based. So, I think you misread it. I said kill TCP/IP in order to replace it by something better and wished that HTTP/2.0 would be that anticipated step…

> Did you even check the alternatives, before going negative?

One does not need alternatives to dislike a system. Alternatives may affect if the system is used, but they don't negate criticism of it.

I don't think HTTP 2 should replace TCP/IP or any other protocol that low in the OSI stack. That is not what HTTP was designed for and I believe throwing out the ideas behind its creation and still calling a new protocol HTTP is disingenuous.

Re: HTTP/2.0 Initial Draft Released

#28

Post by chacham15 »

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…

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 kludge) but not a good replacement/solution for it. The solution given isnt adequate because the solution cookies are trying to solve is maintaining stateless servers. However, they cannot trust the clients and so have to resort to nasty things like hmac'ing the cookies and more easy to mess up security details.

Re: HTTP/2.0 Initial Draft Released

#29

Post by agentS »

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 think all it'd take to change your mind is to load Facebook or Twitter with SPDY and Keep Alives turned off...

Re: HTTP/2.0 Initial Draft Released

#30

Post by jimktrains2 »

chacham15 wrote: post #28
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…

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

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.

> Moreover, it suggests problems that I see (such as the cookie kludge) but not a good replacement/solution for it.

The use of a session identifier, or to use client-side storage until it is needed. The session identifier is not the best solution, but it is a step towards a better system, I believe. Eventually I would like to see it removed.

> However, they cannot trust the clients and so have to resort to nasty things like hmac'ing the cookies and more easy to mess up security details.

You should never trust anything given to you from a client. If I send you a product list, that product list should be opaque ids. The session should be ephemeral and not matter anyway, so there is no reason for it to be signed.

Post reply on HN