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

Hello HTTP/2, Goodbye SPDY

blog.chromium.org

Post reply on HN
Print view View original

131–140 of 181 posts

Re: Hello HTTP/2, Goodbye SPDY

#131

Post by drawkbox »

MichaelGG wrote: post #121
drawkbox wrote: post #82

HTTP/2 is an ugly mess of taking something simple and making it more complex for minimal benefit. It could have been so much better than a binary mess. As engineers, the ones that take simple concepts and add complexity, those are not engineers, those are meddlers. It could be as long lived as XHTML. I was hoping for more SCTP rather than a bunch of cludge on top of what is a pretty beautiful protocol in HTTP 1.1. Pr…

Please tell me where the simplicity in line folding and comments-in-header-values is. Or having special handling for some headers, but not others.

You can still deconstruct the message and it is simple and easier to debug even if less exact.

In binary if there is one flaw the whole block is bunk, i.e. off by one, wrong offset, binary munging/encoding, other things. As an example if you have a game profile that is binary, it can be ruined by binary profiles and corruption on a bad save or transmission.

Binary is all or nothing, maybe that is what is needed for better standards but it is a major change.

What is easier, a json or yaml format of a file or a binary block you have to parse? What worked better HTML5 or XHTML (exactness over interoperability)

Granted most of us won't be writing HTTP/2 servers all day but it does expect more of the implementations to adhere to, for better or worse.

The classic rule in network interoperability is be conservative in what you send (exactness) and liberal in what you accept (expect others to not be as exact).

Re: Hello HTTP/2, Goodbye SPDY

#132

Post by MichaelGG »

drawkbox wrote: post #131
MichaelGG wrote: post #121

Earlier quoted context omitted.

Please tell me where the simplicity in line folding and comments-in-header-values is. Or having special handling for some headers, but not others.

You can still deconstruct the message and it is simple and easier to debug even if less exact. In binary if there is one flaw the whole block is bunk, i.e. off by one, wrong offset, binary munging/encoding, other things. As an example if you have a game profile that is binary, it can be ruined by binary profiles and corruption on a bad save or transmission. Binary is all or nothing, maybe that is what is needed for b…

The "classic rule" aka Postel's Law, has proven to be disastrous. The idea of resuming a corrupted message is a totally flawed concept. At best, it introduces compatibility issues. This is essentially the history of HTML and browsers, each one needing to implement the same bugs as other popular versions.

SIP is another IETF gem, which takes its syntax from HTTP. And guess what? It's impossible to have unambiguous parsing in the wild! Why? The whole liberal in what you accept bad idea. So A interprets \n as a line ending, even though the spec says \r\n. B interprets it another liberal way, and assumes you didn't mean to transmit two newlines in a row, so it'll keep reading headers. End result: you can bypass policy restrictions by abusing this liberal-ness and get A to approve a message that B will interpret in another way. Yikes. And, since the software for both is so widely deployed, there is little hope of solving the problem. In fact, the IETF essentially requires you to implement AI as you're supposed to guess at the "intent" of a message.

So you're sorta proving my point, that people are thinking "oh it's just text" and then writing shitty, sloppy code, and they're giddy cause it sorta worked, even from a two line shell script. And then further generations have to deal with this mess, because these folks just can't bear to get line endings right or whatnot.

Re: Hello HTTP/2, Goodbye SPDY

#133

Post by drawkbox »

MichaelGG wrote: post #132
drawkbox wrote: post #131

Earlier quoted context omitted.

You can still deconstruct the message and it is simple and easier to debug even if less exact. In binary if there is one flaw the whole block is bunk, i.e. off by one, wrong offset, binary munging/encoding, other things. As an example if you have a game profile that is binary, it can be ruined by binary profiles and corruption on a bad save or transmission. Binary is all or nothing, maybe that is what is needed for b…

The "classic rule" aka Postel's Law, has proven to be disastrous. The idea of resuming a corrupted message is a totally flawed concept. At best, it introduces compatibility issues. This is essentially the history of HTML and browsers, each one needing to implement the same bugs as other popular versions. SIP is another IETF gem, which takes its syntax from HTTP. And guess what? It's impossible to have unambiguous par…

Keep in mind you are still going to have lots of these same problems you mention inside the binary blocks and header blocks. Just the specific annoyances of HTTP 1.1 will be gone but new ones will appear.

Going binary does not make it suddenly easier, it just slices it up and adds a layer of obfuscation.

Easier to know what the hell is going on across a wire with current formats and debug them. Utopia interop does not exist so Postel's Law has gotten us this far. Being text no doubt makes it easier to debug and interoperate, otherwise we'd be sending binary blocks instead of json. Unless you control both endpoints, Postel's comes into play and simplicity wins.

We are moving in a new direction for better or worse and going live. I feel like it is slightly off the right path but sometimes you need to take a wrong step like SOAP did to get back to simple. We'll see how it goes.

Re: Hello HTTP/2, Goodbye SPDY

#134

Post by agentS »

drawkbox wrote: post #133
MichaelGG wrote: post #132

Earlier quoted context omitted.

The "classic rule" aka Postel's Law, has proven to be disastrous. The idea of resuming a corrupted message is a totally flawed concept. At best, it introduces compatibility issues. This is essentially the history of HTML and browsers, each one needing to implement the same bugs as other popular versions. SIP is another IETF gem, which takes its syntax from HTTP. And guess what? It's impossible to have unambiguous par…

Keep in mind you are still going to have lots of these same problems you mention inside the binary blocks and header blocks. Just the specific annoyances of HTTP 1.1 will be gone but new ones will appear. Going binary does not make it suddenly easier, it just slices it up and adds a layer of obfuscation. Easier to know what the hell is going on across a wire with current formats and debug them. Utopia interop does no…

A binary protocol's parsing is usually something like read 2 bytes from the wire, decode N = uint16(b[0] Besides, I think this is a moot point, because chances are that less than 100 people's HTTP2 implementations will serve 99.9999% of traffic. It's not like you or I spend much of our time deep in nginx's code debugging some HTTP parsing; I think its just as unlikely we'll be doing that for HTTP2 parsing.

Also, HTTP2 will always (pretty much) be wrapped in TLS. So its not like you're going to be looking at a plain-text dump of that. You'll be using a tool and that tool author will implement a way to convert the binary framing to human-readable text.

Another way to put it is that the vast majority of HTTP streams are not examined by humans and only examined by computers. Choosing a text-based protocol just seems a way to adversely impact the performance of every single user's web-browsing.

Another another way to put it is that there is a reason that Thrift, Protocol Buffers, and other common RPC mechanisms do not use a text-based protocol. Nor do IP, TCP, or UDP, for that matter. And there's a reason that Memcached was updated with a binary protocol even though it had a perfectly serviceable text-based protocol.

Re: Hello HTTP/2, Goodbye SPDY

#135

Post by MichaelGG »

drawkbox wrote: post #133
MichaelGG wrote: post #132

Earlier quoted context omitted.

The "classic rule" aka Postel's Law, has proven to be disastrous. The idea of resuming a corrupted message is a totally flawed concept. At best, it introduces compatibility issues. This is essentially the history of HTML and browsers, each one needing to implement the same bugs as other popular versions. SIP is another IETF gem, which takes its syntax from HTTP. And guess what? It's impossible to have unambiguous par…

Keep in mind you are still going to have lots of these same problems you mention inside the binary blocks and header blocks. Just the specific annoyances of HTTP 1.1 will be gone but new ones will appear. Going binary does not make it suddenly easier, it just slices it up and adds a layer of obfuscation. Easier to know what the hell is going on across a wire with current formats and debug them. Utopia interop does no…

Binary protocols are usually far easier to implement both sending and receiving. There is far less ambiguity.

In fact, the newline problem I mentioned? It was not easier to diagnose, and was only caught by using tools checking it as a binary structure.

Postel was just flat wrong, and history shows us this is so. JSON is popular because it was automatically available in JavaScript, and people dislike the bit if extra verbosity XML introduces. JSON is also a much tighter format than the text parsing the IETF usually implements.

Postel's law also goes against the idea of failing fast. Instead, you end up thinking you're compliant, because implementations just happen to interpret your mistake in the right way. Then one day something changes and bam, it all comes crashing down. Ask any experienced web developer the weird edge cases they have to deal with, again from Postel's law.

And anyways, you know what everyone uses when debugging the wire? WireShark or something similar. Problem solved. Same for things like JSON. Over the past months I've been dealing with that a lot. Every time I have an issue, I pull out a tool to figure it out.

Do you know the real reason for the text looseness? It's a holdover from the '60s. The Header: Value format was just a slight codification of what people were already doing. And why? Because they wanted a format that was primary written and readby humans, with a bit if structure thrown in. Loose syntax is great in such cases. Modern protocols are not written and rarely read by humans. So it's just a waste of electricity and developer time.

Re: Hello HTTP/2, Goodbye SPDY

#136

Post by drawkbox »

agentS wrote: post #134
drawkbox wrote: post #133

Earlier quoted context omitted.

Keep in mind you are still going to have lots of these same problems you mention inside the binary blocks and header blocks. Just the specific annoyances of HTTP 1.1 will be gone but new ones will appear. Going binary does not make it suddenly easier, it just slices it up and adds a layer of obfuscation. Easier to know what the hell is going on across a wire with current formats and debug them. Utopia interop does no…

A binary protocol's parsing is usually something like read 2 bytes from the wire, decode N = uint16(b[0] Besides, I think this is a moot point, because chances are that less than 100 people's HTTP2 implementations will serve 99.9999% of traffic. It's not like you or I spend much of our time deep in nginx's code debugging some HTTP parsing; I think its just as unlikely we'll be doing that for HTTP2 parsing. Also, HTTP…

Agreed on all points. Binary protocols are no doubt better, faster, more efficient and more precise. I use reliable UDP all the time in game server/clients. Multiplayer games have to be efficient, TCP is even too slow for real-time gaming.

Binary protocols work wonderfully... when you control both endpoints, the client and the server.

When you don't control both endpoints is where interoperability breaks down. Efficiency and exactness can be enemies of interoperability at times, we currently use very forgiving systems instead of throwing them out and assert crash dump upon communication error. Network data is a form of communication.

Maybe you are right, since it is binary, only a few hundred implementations might be made and those will be made by better engineers since it is more complex. Maybe HTTP is really a lower level protocol like TCP/UDP etc now. Maybe since Google controls Chrome and the browser lead and has enough engineers to ensure all leading implementations and OSs/server libraries/webservers are correct then it may work out.

As engineers we want things to be exact, but there are always game bugs not found in testing and hidden new problems that we aren't weighing against the known current ones. Getting a something new is nice because all the old problems are gone, but there will be new problems!

It will be an all new experiment we try going away from text/MIME based to something more lower level, complex and exact over simple and interoperability focused. Let's see if the customers find any bugs in the release.

Re: Hello HTTP/2, Goodbye SPDY

#137

Post by frankzinger »

jimktrains2 wrote: post #106
enneff wrote: post #74

Earlier quoted context omitted.

Whatever PHK wants it to be, HTTP/2 is a great step forward from where we are today. Check this out: https://http2.golang.org/gophertiles This is going to make the web so much faster, particular on mobile devices.

> Whatever PHK wants it to be, HTTP/2 is a great step forward from where we are today. A hugely bloated, binary protocol is better than the simple, text-based on we have today? I greatly disagree. HTTP/1.1 could use an update, but HTTP/2 was not the answer.

Only the framing is binary. The PDUs are actually still plain text and 95% (perhaps more) of the semantics of HTTP/1.1 have been retained. Just pointing it out because your comment makes it sound like HTTP/2 is completely binary.

Also, how is HTTP/2 more bloated than HTTP/1.1? It simply adds a little framing; most of the bloat of HTTP/1.1 is retained. And as others have pointed out, HTTP/1.1 is hardly 'simple'.

Somebody on the IETF HTTP WG mailing list (may have been PHK himself) pointed out that their server (Varnish?) spends something like 30% of its CPU time parsing/processing just the Date header because it's in plain text. Plain text is not a panacea. We have nice tools like Wireshark these days which make it much easier for humans to read both binary and plain text protocols.

Re: Hello HTTP/2, Goodbye SPDY

#138

Post by frankzinger »

ademarre wrote: post #104
dragonwriter wrote: post #101

Earlier quoted context omitted.

> So to answer your question: Header compression as employed in HTTP 2.0 helps if you do many requests with similar headers on the same connection. In general, HTTP/2.0 seems to be about improving things if you do many requests over the same connection.

Doing many requests over the same connection is very common.

And one of the fundamental goals of HTTP/2 was to get clients to create only a single connection to a server.

Re: Hello HTTP/2, Goodbye SPDY

#139

Post by MichaelGG »

drawkbox wrote: post #136
agentS wrote: post #134

Earlier quoted context omitted.

A binary protocol's parsing is usually something like read 2 bytes from the wire, decode N = uint16(b[0] Besides, I think this is a moot point, because chances are that less than 100 people's HTTP2 implementations will serve 99.9999% of traffic. It's not like you or I spend much of our time deep in nginx's code debugging some HTTP parsing; I think its just as unlikely we'll be doing that for HTTP2 parsing. Also, HTTP…

Agreed on all points. Binary protocols are no doubt better, faster, more efficient and more precise. I use reliable UDP all the time in game server/clients. Multiplayer games have to be efficient, TCP is even too slow for real-time gaming. Binary protocols work wonderfully... when you control both endpoints, the client and the server. When you don't control both endpoints is where interoperability breaks down. Effici…

>Binary protocols work wonderfully... when you control both endpoints, the client and the server.

IP is all binary and I don't think it's a case of one party controlling all endpoints.

Re: Hello HTTP/2, Goodbye SPDY

#140

Post by cpeterso »

Touche wrote: post #71
dragonwriter wrote: post #18

Earlier quoted context omitted.

> Is HTTPS mandatory on HTTP/2 like it was on SPDY? Not in terms of the protocol spec, but most major browser vendors have indicated that they only intend to support HTTP/2 in-browser over TLS connections, so in practice for typical, browser-targeting use cases, it looks like it will, at least initially.

That's so lame. It's so easy to set up a new website today, it's going to be a huge burden in the future. Some of us still make websites for fun, not as businesses. I guess I have to buy a cheap ssl certificate from some sleezy website every time I feel creative.

You can still use HTTP/1.1.
Post reply on HN