Live data from Hacker News

Hello HTTP/2, Goodbye SPDY

blog.chromium.org

121–130 of 181 posts

Re: Hello HTTP/2, Goodbye SPDY

#121

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.

Re: Hello HTTP/2, Goodbye SPDY

#122

HTTP/2 might have version 2 syndrome. Another better way would have been keep SPDY, as there is usefulness there, separate and then on HTTP/2, to incrementally get there, and use an iteration of something like AS2/EDIINT ( https://tools.ietf.org/html/rfc4130 ) which does encryption, compression and digital signatures on top of existing HTTP (HTTPS is usable as current but not required as it uses best compression/encr…

I've used AS2 extensively (in EDI) and to be frank, fuck that. AS2 is a really bad version of HTTPS, you take HTTPS, you remove the auto-negotiation (email the certificates!), you disable certification CA checking (self-signed for all the things), and then you allow optional HTTPS on top of AS2 (which is a huge nightmare in its own right).

Imagine this scenario, two people want to interconnect, here's the process:

- They insecurely email their public key (self-signed) and URL (no MitM protection)

- You insecurely email your public key (self-signed) and URL

- They have a HTTPS URL

- Now the thing to understand about AS2 is that when you connect to THEM you give them a return URL to confirm receipt (MDN) of the transaction.

- HTTPS becomes a giant clusterfuck in AS2 because people try to use standard popular HTTPS libraries (e.g. that do CA checking, domain checking, and other checks which are fine for typical web-browser-style traffic, but not for specialised AS2 traffic) but in the context of AS2 where certificates are often local self-signed (some even use this for HTTPS), and the URL is rarely correct for the certificate, they fall over all of the time.

- Worse still some sites want to use either HTTP or HTTPS only, so when you connect to a HTTPS URL but give them a HTTP MDN URL sometimes they will work, sometimes they will try the HTTPS version of the URL then fall over and die, and other times they will error just because of the inconsistency.

Honestly I used AS2 for over five years, looking back, it would have saved everyone hundreds of man-hours to have just used HTTPS in the standard way and implement certificate pinning (e.g. "e-mail me the serial number," or heck just list it in your documentation).

The only major advantage of AS2 is the MDNs. However even there there exists massive inconsistency, some return bad MDNs for bad data, while others only return bad MDNs for bad transmission of data (i.e. they only check that what you send is what is received 1:1, so you could send them a series of 0s and get a valid MDN, because they check the data later and then email).

To be honest I hate MDN errors. They don't provide human-readable information in an understandable way. They're designed for automation which rarely exists in the wider world (between millions of different companies with hundreds of systems).

Give me an email template for errors any day, that way there can be a brief generic explanation and formatted data, to better explain things. The only thing MDNs do well is data consistency checking which is legitimately nice, however almost every EDI format I know has that in it already (i.e. segment counters, end segments, etc).

If I was to re-invent AS2, I'd just build the entire thing on standard HTTPS. No HTTP allowed, no hard coded certificates (i.e. you receive a public key the same way your web browser does), certificate pinning would be a key part, and scrap MDNs in place of a hash as a standard header in the HTTPS stream. Normal HTTP REST return codes would be used to indicate success (e.g. 200 OK/202 ACCEPTED, 400 Md5Mismatch/InvalidInput/etc).

That way nobody has to deconstruct an MDN to try and figure out the error. And handling a small handful of HTTP codes is much easier to automate than the information barriage an MDN contains anyway, it is both easier to automate, and easier for humans.

Re: Hello HTTP/2, Goodbye SPDY

#123

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…

Yeah using binary protocols seems to be the new hotness. It all makes me feel so old with my preference for simple ascii text files.

Re: Hello HTTP/2, Goodbye SPDY

#125
post #115
post #113

Well how about the fate of the cute little protocol called QUIC?

Maybe QUIC is the prototype for HTTP/4.

I think they want QUIC to be TCP/2. It's design goals around slow start, congestion control, and RTT reduction are squarely aimed at TCP's short comings.

Re: Hello HTTP/2, Goodbye SPDY

#126

Earlier quoted context omitted.

This attitude is exactly how you make sure that nothing ever changes or improves. It is "the perfect is the enemy of the good" exemplified. HTTP/2 is a huge improvement over HTTP in many very important ways. True, it's not perfect, but guess what? 2 is not the last version number out there. We can switch to HTTP/2 now and fix the rest of the problems with HTTP/3. Moreover, it seems like we are collectively getting be…

I appreciate your optimism, but do realize that there isn't really a massive improvement unless you're Google. I don't see this as worthy of the "/2" suffix; Google might like it because it allows them to make their tech standard, but other than that it's unnecessary marketing. HTTP has never been the bottleneck. I think IPv6 is excellent and a needed, massive improvement especially since IPv4 is no longer tenable. H…

On some small sites I've worked on, switching to SPDY shaved about 20-30% off our load times. And all we had to do was type " SPDY" into our nginx.conf. That's like the definition of a win.

Re: Hello HTTP/2, Goodbye SPDY

#127
post #79

Does anyone know if Cloudflare has plans to implement HTTP/2? RIght now they support SPDY. I found the answer from their blog: "Part of the service CloudFlare provides is being on top of the latest advances in Internet and web technologies. We've stayed on top of SPDY and will continue to roll out updates as the protocol evolves (and we'll support HTTP/2 just as soon as it is practical)."

Since CloudFlare is an OpenResty (nginx + lua) shop, they'll likely get it as soon as it's in nginx.

OpenResty does not include SPDY as there are incompatibilities with it and Lua. But I'm sure CloudFlare has the engineering resources in house to decide what they want to support and when :)

Re: Hello HTTP/2, Goodbye SPDY

#128
post #85

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…

For those slamming HTTP/2.0, how do they rate SPDY?

SPDY is a great prototype that exemplifies why you should write a prototype: to show the problems with your design. It's unfortunate that the HTTP/2.0 committee decided to ignore the flaws and go with the prototype design.

Re: Hello HTTP/2, Goodbye SPDY

#129

Earlier quoted context omitted.

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

I wonder if anyone complaining about binary formats has ever written a high performance parser. Particularly, HTTP's text format, is a mess. You can continue headers from one line to another. You can embed comments into header values . Seriously. Comments. In a protocol's messages. It's moronic and indefensible. Why anyone would prefer that is probably them thinking that text equals easy to implement or something lik…

I never said HTTP/1.1 is perfect. There are many possible optimizations and fixes possible, of which you've alluded to one.

Re: Hello HTTP/2, Goodbye SPDY

#130

HTTP/2 might have version 2 syndrome. Another better way would have been keep SPDY, as there is usefulness there, separate and then on HTTP/2, to incrementally get there, and use an iteration of something like AS2/EDIINT ( https://tools.ietf.org/html/rfc4130 ) which does encryption, compression and digital signatures on top of existing HTTP (HTTPS is usable as current but not required as it uses best compression/encr…

I've used AS2 extensively (in EDI) and to be frank, fuck that. AS2 is a really bad version of HTTPS, you take HTTPS, you remove the auto-negotiation (email the certificates!), you disable certification CA checking (self-signed for all the things), and then you allow optional HTTPS on top of AS2 (which is a huge nightmare in its own right). Imagine this scenario, two people want to interconnect, here's the process: -…

I wasn't saying use AS2 directly but an iteration of all the pain points of before solved, it is a decade old now. There are some things that wouldn't be needed and an iteration needed.

The things that AS/2 got right was that it rides on top of an existing infrastructure of MIME/HTTP. The other part is doing encryption/compression of any type specified by the server/client. And there is some benefit to encryption/compression/digital signing over plain HTTP.

HTTP/2 might be the first protocol for the web that isn't based on MIME for better or for worse. We are headed to a binary protocol that is called Hypertext Transfer Protocol.

HTTP/2 looks more like TCP/UDP or small layer on top of it that you might build in multiplayer game servers. Take a look at the spec and look at all the binary blocks that look like file formats from '93: https://http2.github.io/http2-spec/. It is a munging of HTTP/HTTPS/encryption in one big binary ball. It will definitely be more CPU intensive but I guess we are going live either way!

Plus AS2 was a huge improvement over nightly faxing of orders, large companies were doing this as late as 2003. AS1 (email based) and AS3 (FTP based) were available as well but HTTP with AS2 is what all fulfillment processes use now. And yes it has tons of problems but the core idea of encryption/compression/signatures/receipts over current infrastructure is nice. Everything else you mention exists and definitely are the bad parts though much of that wouldn't be needed in the core.

Post reply on HN