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…
Hello HTTP/2, Goodbye SPDY
121–130 of 181 posts
Re: Hello HTTP/2, Goodbye SPDY
#122HTTP/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…
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
#123HTTP/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…
Re: Hello HTTP/2, Goodbye SPDY
#124Well how about the fate of the cute little protocol called QUIC?
Maybe QUIC is the prototype for HTTP/4.
Re: Hello HTTP/2, Goodbye SPDY
#125Re: Hello HTTP/2, Goodbye SPDY
#126Earlier 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…
Re: Hello HTTP/2, Goodbye SPDY
#127Does 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.
Re: Hello HTTP/2, Goodbye SPDY
#128HTTP/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?
Re: Hello HTTP/2, Goodbye SPDY
#129Earlier 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…
Re: Hello HTTP/2, Goodbye SPDY
#130HTTP/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: -…
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.