21 ms·
Last Call: HTTP2
- dreszg 12y agoShouldn't a protocol as important as HTTP get more than two weeks?
- lazyloop 12y agoNew Year's Eve was also an odd choice for starting a last call.
- aroch 12y agoOr a great choice if you want to shoehorn your wished spec into reality?
- pluma 12y agoMaybe the W3C didn't want a repeat of what happened with XHTML2.
- aroch 12y agoIf memory serves there were a number of issues with XHTML2, chief among them being it didn't serve the original intent of XHTML very well. HTTP/2 has good meaning but some of the deign choices were made because Google wanted them not because they were necessarily best (at least from my understanding as an interested spectator).
- pas 12y agoCould you expand on that? Is there a list of these features, or at least a blogpost that interested parties could read to quickly get up to speed with the special interest influences currently observable in the spec?
- jacquesm 12y agohttp://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/?include_text=1 http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/?in... Tons of change for marginal gain. And of course the old stuff will need to be supported at the same time.
- deleted 12y ago[deleted]
- pconner 12y agoThe Heartbleed bug was committed on New Years Eve.
- cubano 12y agoPerhaps ironic would be a better word for it?
- jvehent 12y agoIt got 3 years :)
- jacquesm 12y agoGiant mistake in the making. HTTP is elegant, HTTP2 is a monstrosity. Edit: downvoters: please explain what's to like about HTTP2. I have a very hard time finding anything to like. For example: no more easy debugging on the wire, another TCP like implementation inside the HTTP protocol, tons of binary data rather than text and a whole slew of features that we don't really need but that please some corporate sponsor because their feature made it in. Counter examples appreciated. Compare: http://tools.ietf.org/html/rfc1945 http://tools.ietf.org/html/rfc1945
- Afforess 12y agoHTTP is not elegant. I can disprove its elegance with one word: referer [sic]
- jacquesm 12y agoReferrer was a nice idea that led to a lot of trouble. Agreed, that wasn't the most brilliant idea but in a world of one-way-links a way to establish the origin of incoming traffic so you could simulate reciprocal links must have seemed like a good idea at the time. Keep in mind that Hypertext as it was originally envisioned by Ted Nelson had nothing but two way links, doing one-way links broke with the view of the day in a pretty drastic manner (and actually made the whole thing possible), so I think some leeway here is allowed.
- kmowery 12y agoI believe they were referencing that in English it is "referrer", but has been misspelled in HTTP forever as "referer".
- jacquesm 12y agoWell, in this draft linked here they spell 'server' as 'sever' in one instance so I guess that evens up the score. But the GGP had a point, referrer is a troublesome bit in many ways and he seemed to be aware of the spelling error so I chose to answer the meat of the item rather than to take it in the most simplistic way (after all, making spelling errors like this really does happen, one guy I knew had sandblasted 150 glass doors with a text when I happened to walk by and pointed out that pneumatical has an 'n' in the second position (and not an 'm'...). For some reason he didn't seem all that happy.
- Pxtl 12y agoAnybody got a good summary of HTTP2 features (which I know could be described as "everythign plus the kitchen sink")?
- shurcooL 12y agoIt's mostly more efficient (in terms of average latency, speed and total bandwidth). Kinda like BMP format to PNG format (with compression and alpha channels). Yes, BMP is a lot simpler and you can find out the RGB of any pixel by looking at pixels[y*width+x] while with PNG you have non-trivial complexity with compression, etc. But the size efficiency is worthwhile.
- pdkl95 12y agoThis analogy exaggerates the bandwidth savings. Converting from uncompressed BMP to compressed PNG can easily save over half of the file size; even 10:1 compression is common for some images. The bandwidth savings in HTTP2 are much smaller, and are probably only significant in aggregate.
- stephen_g 12y agoTrue - the bandwidth savings aren't huge. What you do get with HTTP/2 is the ability to use bandwidth a lot more efficiently. Because of TCP's congestion control, such as slow-start, doin a different TCP connection for each file, as HTTP/1.1 does, is actually a fairly terribly inefficient for transferring small files. One way that web developers have tried to get around this is to combine resources together - such as having huge combined javascript and CSS files, and big sprite sheet images. But this messes up caching - if I change a 20KB source file that is part of a half meg combined JS file, then you have to redownload the entire file. Another problem is that you're limited to how many HTTP requests the browser will make to a single domain at once, so you have to wait around for files to finish before others will download. You can try sharding the files across different subdomains but it's a suboptimal solution. The multiplexing in HTTP/2 solves these problems. You can send a bunch of files at once in one connection without repeating the (necessary) slowness of TCP slow start for every file, and the browser realises that they're different, so can cache them separately. This can translate into noticeably faster page load times.
- hjfgdx 12y agoThat mess should have never made it to last call. https://www.varnish-cache.org/docs/trunk/phk/http20.html https://www.varnish-cache.org/docs/trunk/phk/http20.html
- magila 12y agoIt feels like HTTP2 is a classic case of "something must be done, this is something, therefor it must be done". Clearly there are shortcomings in HTTP 1.1 which would be nice to address. Google to their credit spent a lot of resources coming up with a solution which met their needs. The problem is that when Google then went to httpbis the people on the WG apparently took it as an imperative that _something_ must be released as HTTP2 in relatively short order. There was a halfhearted attempt to open things up to competing ideas, but unsurprisingly SPDY was by far the most mature of the proposals. Thus SPDY became the heir apparent to HTTP by default, despite being a mud ball of complexity and layering violations.
- sanxiyn 12y agoWhile HTTP2 is a layering violation incarnate, apparently properly layered solution is undeployable. Perfect is the enemy of good.
- barnacs 12y agoWhy is it undeployable? I mean, we're talking about a new standard here. Anything goes. It doesn't have to happen tomorrow. Google only has influence over their HTTP client and server implementation and with such restrictions, SPDY was the best they could come up with. That doesn't mean the new global standard can't dump TCP for example.
- jacquesm 12y agoGoogle also strongly influences Mozilla through sponsorship agreements. Note how the only names on this document are Mozilla and Google employees.
- Havvy 12y agoMozilla and Google no longer have any sponsorship agreements. And I can guarantee you that to most developers in Mozilla, that agreement never gave any technical or political credence to Google and its actions.
- tptacek 12y agoWhat's a "layering violation"? Who draws the borders between the "layers"? Isn't "layering" just another way of invoking the status quo?
- magila 12y agoHTTP2 is a layering violation because it implements a new layer of multiplexing and flow control on top of the existing layer of multiplexing and flow control. Rather than solving the problems with TCP they slapped a band-aid on top because that allowed them to get to market faster. In the short term it's a win for Google et al, but in the long term this sort of thing will turn the internet into (even more of) an unmanageable mess.
- fubarred 12y agoSSL/TLS is something that needs to be thrown away and start over (not that it would happen realistically without immense pressure after another spectacular failure). The over-complexity of X509 and the ease of which one can acquire legitimate certs for domains one doesn't own is appalling. From recent revelations, it's even more troublesome the number and scale of exfiltration of private keys, making it possible for some state actors to MITM 10's-100's megaconnections. (One has to put on their tinfoil hat to estimate how many countries have successfully placed staff in core IT/webops positions of Fortune 100 that are then able to leverage that access... Not to mention high-level engagement. [The direct approach conversation might go like this: "gives your keys or we will send in agents to expose embarrassing details about your org and we will still get the keys anyway."]) Perhaps folks like 'cperciva would be kind enough to propose a single, simple TOML-based cert system that is extremely lightweight with the fewest of features. (Not that TLS/SSL would change without focused, sustained herculean effort immediately after yet another Heartbleed.)
- erglkjahlkh 12y agoExtremely light weight? It may be complex, but x509 is based on ASN.1 and one of the most compact and efficient way to represent and handle certificates. There are so many tools supporting it properly, and many of them are extremely hard to change (especially HSMs) because there are actual dependencies, that I wouldn't bother. The problems are mostly in SSL & TLS protocols, not in the certificates. We should get a new alternative that would be designed to be easily implementable, and it should get proper reference implementation (with proofs of correctness, which by the way are available for X509... That's the only part that is verifiable afaik).
- tptacek 12y agoWhat exactly does the ease of acquiring a bogus cert have to do with the complexity of X.509?
- nly 12y agoI'm so glad HTTP/2 is finally here to save us from the horrors of the web stack by providing a decent session layer, privacy preserving defaults, cross-domain and efficient differential caching, as-near-as-can-be bulletproof password-based authentication, and mandatory encryption. Oh, wait... maybe that was a dream.
- TwoBit 12y agoI am against this. This is not a good standard. It's a response to Google 's Microsoft-like protocol hack.
- gmzll 12y agoThe fact that M. Belshe is listed as the primary author, when he didn't even work on the document, says it all. This is just Google forcing the IETF to gold plate SPDY.
- youngtaff 12y agoMike continues to contribute to the standard long after he's left Google
- lkrubner 12y agoBack in 1989 Sir Tim Berners-Lee put a lot of careful thought into the design of a protocol for sharing documents using IP/TCP. However, when Ajax and Web 2.0 got going circa 2004, the emphasis was on offering software over TCP, and for that the HTTP protocol was poorly suited. Rather than carefully rethink the entire stack, and ideally come up with a new stack, the industry invented what amount to clever hacks, such as WebSockets, which were then bolted into the existing system, even relying on HTTP to handle the initial "handshake" before the upgrade. What I would like to see is the industry ask itself, can HTTP be retro-fitted to work for software over TCP or UDP? It is clear that HTTP is a fantastic protocol for sharing documents. But it is what we want when our goal is to offer software as a service? I'll briefly focus on one particular issue. WebSockets undercuts a lot of the original ideas that Sir Tim Berners-Lee put into the design of the Web. In particular, the idea of the URL is undercut when WebSockets are introduced. The old idea was: 1 URL = 1 document = 1 page = 1 DOM Right now, in every web browser that exists, there is still a so-called "address bar" into which you can type exactly 1 address. And yet, for a system that uses WebSockets, what would make more sense is a field into which you can type or paste multiple URLs (a vector of URLs), since the page will end up binding to potentially many URLs. This is a fundamental change, that takes us to a new system which has not been thought through with nearly the soundness of the original HTTP. Slightly off-topic, but even worse is the extent to which the whole online industry is still relying on HTML/XML, which are fundamentally about documents. Just to give one example of how awful this is, as soon as you use HTML or XML, you end up with a hierarchical DOM. This makes sense for documents, but not for software. With software you often want either no DOM at all, or you want multiple DOMs. Again, the old model was: 1 URL = 1 document = 1 page = 1 DOM We have been pushing technologies, such as Javascript and HTML and HTTP, to their limits, trying to get the system that we really want. The unspecified, informal system that many of us now work towards is an ugly hybrid: 1 URL = multiple URLs via Ajax, Websockets, etc = 1 document (containing what we treat as multiple documents) = 1 DOM (which we struggle against as it often doesn't match the structure, or lack of structure, that we actually want). Much of the current madness that we see with the multiplicity of Javascript frameworks arises from the fact that developers want to get away from HTTP and HTML and XML and DOMs and the url=page binding, but the stack fights against them every step of the way. Perhaps the most extreme example of the brokenness are all the many JSON APIs that now exist. If you do an API call against many of these APIs, you get back multiple JSON documents, and yet, if you look at the HTTP headers, the HTTP protocol is under the misguided impression that it just sent you 1 document. At a minimum, it would be useful to have a protocol that was at least aware of how many documents it was sending to you, and had first-class support for counting and sorting and sending and re-sending each of the documents that you are suppose to receive. A protocol designed for software would at least offer as much first-class support for multiple documents/objects/entities as TCP allows for multiple packets. And even that would only be a small step down the road that we nee d to go. A new stack, designed for software instead of documents, is needed. I would have been happy if they simply let HTTP remain at 1.1 forever -- it is a fantastic protocol for exchanging documents. And then the industry could have focused its energy on a different protocol, designed from the ground up for offering software over TCP.
- drawkbox 12y agoTechnology ebbs and flows, I feel like this is a backdrift like XHTML but it will flow again. Binary in Hyper Text Transfer will never seem right. I understand it is more performant but it always creates more bugs, ask any game developer, binary needed but also living on the edge of indexes/ordering/headers/harder to debug/etc. Indexing, overflows, incorrect implementations, will follow. Many of the advancements in HTTP2 are good but there are some steps backwards we'll have to re-learn again. It isn't all about performance when it comes to correct interoperability as standards lead to many interpretations, it is why XML then JSON won data transfer, it is easy to interoperate, yes binary is more efficient over the wire but not to interoperate. Should we go back to binary formats for data exchange on the network? The protocol level is lower level but still it has been beneficial in the current standards to spreading innovation with lower barriers to understanding. HTTP2 is one of those 'version 2' of an app that some of the legacy genius of it was lost and overlooked in the redesign, like simplicity. An engineers job is to make something complex into something simple and blackboxing data isn't simplifying it.
- nemothekid 12y ago>HTTP2 is one of those 'version 2' of an app that some of the legacy genius of it was lost and overlooked in the redesign, like simplicity. Calling HTTP1/1.1 genius sounds like an "intelligent design" argument (as opposed to "evolution"), and I think detracts from what makes it good. What makes more sense to me is HTTP1/1.1 was invented and then we hacked/adapted/"evolved" on top of it to get it to do what we want. It wasn't the spec that was genius - it was the effort of countless engineers overtime the crammed a genius, trillion dollar industry into an "okay" spec (The same way it was done for HTML/CSS/JS). in that vein, the whole binary/plaintext header arguments seem a lot closer to "this is the way my father did it" rather than "this is the most efficient way". To counter your XML/JSON example - I would argue they won over binary formats because there a huge need for humans to write & edit data exchange structures. OTOH, I can't remember the last time I sent/edited/created HTTP Headers by hand. While JSON has tons of uses and is stored in countless places(config, user data, state data), HTTP servers are the only services that seem to care about HTTP headers.
- 12y ago
- thomasfoster96 12y agoPushing content to the client, emphasis on encrypted and secure connections - woo! Waiting months/years for HTTP\2 support to appear in all the tools I use - :( ....
- cdent 12y agoHTTP2 is yet another in a long series of developments that feel like the corporate takeover of the commons. Sure there are plenty of excellent features in it but they are primarily of benefit to systems doing huge (on lots of dimensions) stuff. Is this the inevitable path of any technology which has initial promise for enabling individual public expression?
- organsnyder 12y agoMy opinion is exactly the opposite. Large organizations have the resources (person-hours, server infrastructure, etc.) to do all of the hacks required to get decent performance out of HTTP/1.x. Smaller shops aren't as likely to have the time to do domain sharding, sprites, etc.; yes, there are tools and services to do a lot of that work for you, but it still adds complexity.
- alexwilliamsca 12y agoLet's just skip this like we did with IPv5.