Here is a question I hoped to be answered, but it wasn’t: Why doesn’t the HTTP/2 protocol use SRV DNS records¹? Using it would solve some real problems:<p>1. The well-known resilience of mail can be largely attributed to its use of MX records to specify the use of backup servers and/or load balancing. SRV records are essentially a generalization of MX records for any service, not just mail, so using SRV records would bring this benefit to any protocol which uses them.<p>2. The problem of “www” or no “www” would be entirely eliminated; no need for non-standard so-called ANAME or ALIAS “records”. Just imagine – if, in an alternate universe, mail servers <i>hadn’t</i> used MX records, it would then have been necessary to have an A record on the bare domain name, and later, when the Web was created in this alternate universe, the web server would have to be the <i>same</i> server as the mail server, since both now would use the bare domain name. In our universe, this position is now solely occupied by the HTTP protocol, which causes lots of pain in the DNS when redundant (and harder to update) A records need to be put on the bare domain name just for HTTP. Not to mention IPv6, which, for HTTP to work, requires an <i>additional</i> AAAA record on the bare domain.<p>3. The “everything is on port 80, let’s reinvent everything on top of HTTP” problem could certainly have been entirely avoided, and could be slowly fixed, by using SRV records. (A server concerned about clients needing to traverse old-style restrictive firewalls could provide a low-priority port 80 server as a fallback.)<p>① <i>A DNS RR for specifying the location of services (DNS SRV)</i> <a href="https://tools.ietf.org/html/rfc2782" rel="nofollow">https://tools.ietf.org/html/rfc2782</a>
Under the "Why Revise HTTP"
<a href="http://http2.github.io/faq/#why-revise-http" rel="nofollow">http://http2.github.io/faq/#why-revise-http</a> section the summary is basically "So we don't have to be as mindful of the number of HTTP requests" Is this really a compelling reason? I would argue it is not, especially if we have to trade a human-readable and easy to troubleshoot text-based protocol with a binary one. It seems like we are solving a small problem by creating a larger one.
Brad Fitzpatrick is working on a Go implementation of HTTP/2 at <a href="https://github.com/bradfitz/http2" rel="nofollow">https://github.com/bradfitz/http2</a>.
I'm using nginx with SPDY and I've noticed that if I start downloading a file, I can no longer load pages on the website. I get an error message in Firefox saying "The connection was interrupted". If I do a ctrl+F5 then I can continue browsing the site. Does this have to do with the "one TCP connection"?
In my opinion HTTP/2 is too complex.<p>I think the better route is to investigate how HTTP/1.1 could be layered atop multiplexing transport protocols like SCTP.<p>It might take 10 years to reach wide deployment, but HTTP/1.1 over TCP is working just fine anyways.
> Spriting, data-inlining, domain sharding, and concatenation. These hacks are indications of underlying problems in the protocol itself.<p>While this is true, I don't think HTTP/2 will or should negate some of these. Precomputing things like minification and concatenation will certainly reduce load and always increase capacity. Human-readable code is only useful for humans, and during transfer, storage, parsing, etc., it's just plain inefficient. Also, with spriting and concat, fewer files means more of the information you know you need is at the same place in disk or memory, speeding access at a low level.
This page appears to be Twitter branded at certain window sizes. Specifically, if the Twitter icon in the header happens to show up more or less centered, it looks just like the header on Twitter (when you're logged in). Maybe use text for that link, or have another logo in the header somewhere?
Amusingly, many of the design decisions of HTTP/2 were made the same way in Macromedia Flash. Binary representation and multiplexing of streams to improve the user experience are both used in Flash.
Never understood why the re-use of the "<a href="http://"" rel="nofollow">http://"</a> protocol, why not us "http2://" instead.