10 ms·

HTTP/2 Is Done

437 points by stephenjudkins 12y ago

jgrahamc 12y ago
[placeholder for commentary about how HTTP/2 is a bad protocol because it's binary and everything could have been fixed in a text protocol follow by ad nauseum repetition of all the same old arguments]
- angersock 12y ago
  You just saved me like ~10 minutes. Thanks bro.
- stonogo 12y ago
  [placeholder for long-winded brogrammer mansplaining the need to implement TCP over TCP instead of expending even the slightest effort in retaining the features that made the protocol popular in the first place]
- tokyo1000 12y ago
  The fact that there's so much disagreement and discontent surrounding this should concern everyone involved. Trade-offs are being made that may benefit some people and organizations, but these trade-offs are also causing significant problems for others. While there has always been some degree of disagreement regarding technological matters, I think we're really seeing a lot more of it these days, especially when it comes to projects that are open source, or standards that are supposedly open. HTTP/2 is a good example. But we've also got GNOME 3, systemd, how systemd has been included in various Linux distros, many of the recent changes to Firefox, and so forth. Not only is this disagreement more prevalent, it's also much harsher than what we've seen in the past. Instead of seeing compromise, we're seeing marginalization. We're repeatedly seeing a small number of people force their preferences upon increasingly larger masses of unwilling victims. We're seeing consensus being claimed, but this is only an illusion that barely masks the resentment that is building. What we're seeing goes beyond mere competition between factions with differing situations. We're seeing any sort of competition, or even just dissent, being highly discouraged, suppressed, or even prevented wherever possible. Those whose needs aren't being met end up backed into a corner and shunned, rather than any effort being put into cooperating with them, with helping them, or even just with considering their views. This isn't a healthy situation for the community to be in, especially when it comes to projects that allegedly pride themselves on openness. We've already seen this kind of polarization severely harm the GNOME 3 project. We're seeing things get pretty bad within the Debian project. And the HTTP/2 situation hasn't been very encouraging, either.
  - Chlorus 12y ago
    "We're seeing any sort of competition, or even just dissent, being highly discouraged, suppressed, or even prevented wherever possible." Could you please elaborate on this point?
    - tokyo1000 12y ago
      jgrahamc's comment that I replied to is a mild example of this. If people are repeatedly raising the same concerns whenever HTTP/2 is discussed, then there are clearly issues with it that aren't being sufficiently dealt with. Writing off their problems as merely being "all the same old arguments", and discouraging discussion of them, doesn't exactly help solve these problems. Things tend to be particularly bad when it comes to systemd, though. It isn't unusual to see censorship occur, either in the form of unjustifiable downmodding, comment deletion, or even the banning of participants, depending on the venue. We also are seeing it become increasingly difficult for Debian users, for example, to opt out of using systemd, or to easily switch to an alternative init system. Instead of people with different preferences or interests working together, or even working independently, we're more often seeing one group of people quench the ability of the competing groups to participate or to even have choice. When discussion is stifled, and choice is taken away, the outcome will likely never be positive.
      - marcosdumay 12y ago
        Count me in the naysayer group. I don't like HTTP/2. But comparing it with systemd is completely unreasonable. When a huge group of people complained about HTTP/2, it become an optional standard, and HTTP/1.1 is officially the only web standard capable of satisfying a big number of use-cases. No choice is being taken away, it's just a bad standard that is being pushed at server maintainers.
  - matt_kantor 12y ago
    > While there has always been some degree of disagreement regarding technological matters, I think we're really seeing a lot more of it these days I don't have any way to dispute this, but I don't think it's easy to provide evidence for it either. I feel that there may simply be more individuals involved in these kinds of discussions these days. Obviously at some point you have to stop discussing something and start building it. That's not to say that discussion isn't important or shouldn't be encouraged (quite the contrary), but I find it very difficult to make generalizations about where the line should be drawn.
deleted 12y ago
[deleted]
lazyloop 12y ago
HTTP/2 is a bad protocol, that much is clear by now. Luckily most of us won't have to deal with it, because it will be deployed merely as an optimization, with a new generation of reverse-proxy servers, like H2O. https://github.com/h2o/h2o https://github.com/h2o/h2o
- andrewstuart2 12y ago
  Care to at least explain why you think it's a bad protocol?
  - mattbessey 12y ago
    Well he doesn't need to, by his own proclamation there's no arguing! /s
  - lazyloop 12y ago
    Poul-Henning Kamp (the author of Varnish) explained it best. http://queue.acm.org/detail.cfm?id=2716278 http://queue.acm.org/detail.cfm?id=2716278
    - IvyMike 12y ago
      HN discussion: https://news.ycombinator.com/item?id=8850059 https://news.ycombinator.com/item?id=8850059
    - DannyBee 12y ago
      Except, as HN has mostly ripped him apart for, his argument is very weak at best. He goes into zero detail, and where he does, it says things like "likely to increase CO2 consumption"? Seriously?
    - jamescostian 12y ago
      Do you have another explanation which hasn't been torn apart by Hacker News commentators already? As someone who would like to avoid going to the trouble to implement HTTP2, I'm not being sarcastic - I truly want to know why HTTP2 is so bad, and I want to read it from someone who backs up their words with cold-hard facts
logicallee 12y ago
this seems nice, pretty conservative. https://tools.ietf.org/html/draft-ietf-httpbis-http2-17 https://tools.ietf.org/html/draft-ietf-httpbis-http2-17 " Abstract This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. " all these changes seem good without a large change, just an improved user experience. (the Introduction section is also good - "HTTP/2 addresses these issues by defining an optimized mapping of HTTP's semantics to an underlying connection", I'd quote more but why not click through the link at the top of this comment. basically just some compression of headers, none of the funky stuff to keep connections alive for server push, prioritizing important requests, etc. all without changing semantics much - great.)
thomasfoster96 12y ago
I know I'm apparently not meant to be, but I'm genuinely keen to start using HTTP/2. If you've been following some of the things being done in HTML recently (rel=subresource, rel=dns-prefetch), I think it's starting to become a little obvious that for most people HTTP is the bottleneck. HTTP/2 seems to be a good, solid step forwards. If it's not perfect, well, it doesn't have to be; 2 isn't the last number.
- deleted 12y ago
  [deleted]
- Practicality 12y ago
  Agreed. I can't wait to start using it. Speed is a very important feature.
bgentry 12y ago
It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!
- bgentry 12y ago
  If anyone wants to learn more about optimizing for HTTP/2, unwinding HTTP/1.1 hacks, and strategies to optimize for both versions at the same time, Ilya Grigorik's "High Performance Browser Networking" is an excellent resource: http://chimera.labs.oreilly.com/books/1230000000545/ch13.html#_removing_1_x_optimizations http://chimera.labs.oreilly.com/books/1230000000545/ch13.htm...
  - colin_jack 12y ago
    Couldn't agree more, its also one of the best written tech books I've ever read.
  - hueving 12y ago
    If it requires a book to optimize for HTTP2, doesn't that counter your comment's parent's point? It's supposed to be simple.
    - rogeryu 12y ago
      Simple to use doesn't mean simple to create. Even a simple and small code base doesn't mean the think-process preceding the actual programming was simple.
    - exogen 12y ago
      One can write a book about literally anything. But besides that, it already "required" a book – at least two of them in fact, both published before Google even announced SPDY: "High Performance Web Sites" [1] in 2007 and its sequel "Even Faster Web Sites" [2] in 2009, both by Steve Souders. What are they about? Essentially, optimizing your HTTP responses for the ways in which actual web browsers make HTTP requests. Any web performance analysis tool worth using (like YSlow and PageSpeed – both of which Steve Souders was involved in btw) recommended the practices outlined in those books. So, no. I don't think a new book with updated practices says anything about the protocol. The optimization tips from this book will simply become widespread common knowledge the same way they did in the past. [1] http://shop.oreilly.com/product/9780596529307.do http://shop.oreilly.com/product/9780596529307.do [2] http://shop.oreilly.com/product/9780596522315.do http://shop.oreilly.com/product/9780596522315.do
deleted 12y ago
[deleted]
tropicalmug 12y ago
I wish instead of a protocol improvement that focused solely on network resources, the next version will also include improvements for users such as encryption by default and doing away with cookies.
- numbsafari 12y ago
  You can begin today to do away with cookies on your own sites and services. Start implementing richer clients and leveraging Open ID Connect and OAuth2. Cookies solve real use case problems. Unless we all start building and experiencing and improving the alternatives, progress won't be made. That said, good luck on getting rid of cookies all together.
  - ecthiender 12y ago
    Excuse my ignorance, but how can I do session management without using cookies? I tried searching on the net, but it doesn't seem to give any concrete/valid results. Can you give me any pointers? Edit: I do use OAuth2.0 on my services and use Mozilla Persona to manage user logins, but I am not clear how can I keep sessions between requests if I don't use cookies.
    - MichaelGG 12y ago
      HTML5 has local storage, so you can put auth tokens in there and only send them when you need them, versus on every request.
      - stephenr 12y ago
        So rather than just using cookies effectively, you can make your application absolutely dependant on both JavaScrip and XHR?
        omeid2 12y ago
        "Applications" on the web are inherently dependant on JavaScript and most often XHR too, but I do agree that using Local Storage has little to no advantage over Cookies.
bantic 12y ago
I read Daniel Stenberg's (he is a maintainer of curl, I think?) "http2 explained" pdf the other day, and it's by far the best comprehensive explanation of http2 that I have seen. Well worth a read if you're curious what's coming with http2. http://daniel.haxx.se/http2/ http://daniel.haxx.se/http2/
- pgl 12y ago
  Hacker News thread: https://news.ycombinator.com/item?id=9038613 https://news.ycombinator.com/item?id=9038613
RunningWild 12y ago
Another year, another wheel reinvented.
- Intermernet 12y ago
  I know you're being somewhat facetious, but have you considered how much the wheel has actually been reinvented? The first wheels were probably logs under rocks. Then axles got developed, then spokes, then tyres etc. Everything from the gyroscope to the LHC can attribute it's beginnings to the humble wheel. Reinvention is, if not always good, always admirable.
  - RunningWild 12y ago
    Up to a point, I agree. Beyond that point it becomes churn and reinvention for the sake of itself.
cm2187 12y ago
Stupid question: would you rather have server push serving static content from the application server or a CDN for the static assets? If a CDN, how can server push be leveraged when the assets are not related to each others (and the server can't tell in which order they will be requested).
- youngtaff 12y ago
  Where sites serve the base page through a CDN, then the CDN has the potential to start making intelligent decisions on what should be pushed. As the simplest level this might be just the CSS, and JS in the <head> but obviously as different UA's behave differently there's scope for much granular optimisations.
  - cm2187 12y ago
    That's the easy, but relatively rare scenario. Today most content is dynamic. Naively, it looks to me that server push will mostly be an improvement for small websites that do not use a CDN, but I can't see how it can coexist with a CDN. Or it would require a new syntax, where the html tells the browser to start connecting to the CDN with this particular URL, which contains a token, and should be downloaded first which would tell the CDN that a particular list of assets will be needed for that page, and then the CDN will use server push to send these static assets. Alternatively the CDN would become a proxy for the underlying html page, which would still be generated by the application server. That would probably be simpler.
    - youngtaff 12y ago
      CDNs aren't limited to just static content, it's quite common for large dynamic sites to deliver their base pages though CDNs. They can use features like ESI to assemble the final page on the edge from static and dynamic parts, or they can just act as a proxy to the origin with the dynamic page generated there. Even when the CDN is just acting as a proxy back to the origin there can be performance advantages e.g. lower latency TCP and TLS negotiation between edge to client, and permanent connection between edge and origin i.e. single TCP negotiation for all clients, larger congestion windows leading to higher throughput. In short CDNs aren't just for static content!
blueskin_ 12y ago
Did that anti-encryption backdoor get put in in the end or not? News reporting on it went quiet a while back...
theallan 12y ago
Does anyone have any information about HTTP/2 development in Apache? Searching the bug list I don't immediately see anything and the only thing I can find from a Google search is a mailing list entry with someone asking about http/2 development and being told that it isn't really being worked on [1] [1] http://mail-archives.apache.org/mod_mbox/httpd-dev/201408.mbox/%3CCALK=YjONaJzKsYouzrYJrhT=ZXW6oHbZCgtBH9nfi5wuP=qwDw@mail.gmail.com%3E http://mail-archives.apache.org/mod_mbox/httpd-dev/201408.mb...
scorpwarp23 12y ago
I'd really like to know what this means in the context of MeteorJS - particularly how the HTTP Push feature will affect MeteorJS in the long run. Does it make MeteorJS redundant?
scorpwarp23 12y ago
I'd really like to know what this means in the context of MeteorJS - particularly how the HTTP Push feature will affect MeteorJS in the long run. Does it make MeteorJS redundant?
orthecreedence 12y ago
Question: I originally heard HTTP/2 would force TLS and have it baked into the protocol. Is this still the case? If so, is this going to be strictly enforced? I think it's a really terrible idea to melt a protocol and a transport together. Or am I misunderstanding how it works?
- garraeth 12y ago
  This says yes for Chrome and FF but no such requirement for cURL or IE: http://daniel.haxx.se/http2/ http://daniel.haxx.se/http2/ How accurate it is, I'm not sure.

437 points by stephenjudkins 12y ago

[placeholder for commentary about how HTTP/2 is a bad protocol because it's binary and everything could have been fixed in a text protocol follow by ad nauseum repetition of all the same old arguments]

angersock 12y ago
You just saved me like ~10 minutes. Thanks bro.
stonogo 12y ago
[placeholder for long-winded brogrammer mansplaining the need to implement TCP over TCP instead of expending even the slightest effort in retaining the features that made the protocol popular in the first place]
tokyo1000 12y ago
The fact that there's so much disagreement and discontent surrounding this should concern everyone involved. Trade-offs are being made that may benefit some people and organizations, but these trade-offs are also causing significant problems for others. While there has always been some degree of disagreement regarding technological matters, I think we're really seeing a lot more of it these days, especially when it comes to projects that are open source, or standards that are supposedly open. HTTP/2 is a good example. But we've also got GNOME 3, systemd, how systemd has been included in various Linux distros, many of the recent changes to Firefox, and so forth. Not only is this disagreement more prevalent, it's also much harsher than what we've seen in the past. Instead of seeing compromise, we're seeing marginalization. We're repeatedly seeing a small number of people force their preferences upon increasingly larger masses of unwilling victims. We're seeing consensus being claimed, but this is only an illusion that barely masks the resentment that is building. What we're seeing goes beyond mere competition between factions with differing situations. We're seeing any sort of competition, or even just dissent, being highly discouraged, suppressed, or even prevented wherever possible. Those whose needs aren't being met end up backed into a corner and shunned, rather than any effort being put into cooperating with them, with helping them, or even just with considering their views. This isn't a healthy situation for the community to be in, especially when it comes to projects that allegedly pride themselves on openness. We've already seen this kind of polarization severely harm the GNOME 3 project. We're seeing things get pretty bad within the Debian project. And the HTTP/2 situation hasn't been very encouraging, either.
- Chlorus 12y ago
  "We're seeing any sort of competition, or even just dissent, being highly discouraged, suppressed, or even prevented wherever possible." Could you please elaborate on this point?
  - tokyo1000 12y ago
    jgrahamc's comment that I replied to is a mild example of this. If people are repeatedly raising the same concerns whenever HTTP/2 is discussed, then there are clearly issues with it that aren't being sufficiently dealt with. Writing off their problems as merely being "all the same old arguments", and discouraging discussion of them, doesn't exactly help solve these problems. Things tend to be particularly bad when it comes to systemd, though. It isn't unusual to see censorship occur, either in the form of unjustifiable downmodding, comment deletion, or even the banning of participants, depending on the venue. We also are seeing it become increasingly difficult for Debian users, for example, to opt out of using systemd, or to easily switch to an alternative init system. Instead of people with different preferences or interests working together, or even working independently, we're more often seeing one group of people quench the ability of the competing groups to participate or to even have choice. When discussion is stifled, and choice is taken away, the outcome will likely never be positive.
    - marcosdumay 12y ago
      Count me in the naysayer group. I don't like HTTP/2. But comparing it with systemd is completely unreasonable. When a huge group of people complained about HTTP/2, it become an optional standard, and HTTP/1.1 is officially the only web standard capable of satisfying a big number of use-cases. No choice is being taken away, it's just a bad standard that is being pushed at server maintainers.
- matt_kantor 12y ago
  > While there has always been some degree of disagreement regarding technological matters, I think we're really seeing a lot more of it these days I don't have any way to dispute this, but I don't think it's easy to provide evidence for it either. I feel that there may simply be more individuals involved in these kinds of discussions these days. Obviously at some point you have to stop discussing something and start building it. That's not to say that discussion isn't important or shouldn't be encouraged (quite the contrary), but I find it very difficult to make generalizations about where the line should be drawn.

deleted 12y ago

[deleted]

lazyloop 12y ago

HTTP/2 is a bad protocol, that much is clear by now. Luckily most of us won't have to deal with it, because it will be deployed merely as an optimization, with a new generation of reverse-proxy servers, like H2O. https://github.com/h2o/h2o https://github.com/h2o/h2o

andrewstuart2 12y ago
Care to at least explain why you think it's a bad protocol?
- mattbessey 12y ago
  Well he doesn't need to, by his own proclamation there's no arguing! /s
- lazyloop 12y ago
  Poul-Henning Kamp (the author of Varnish) explained it best. http://queue.acm.org/detail.cfm?id=2716278 http://queue.acm.org/detail.cfm?id=2716278
  - IvyMike 12y ago
    HN discussion: https://news.ycombinator.com/item?id=8850059 https://news.ycombinator.com/item?id=8850059
  - DannyBee 12y ago
    Except, as HN has mostly ripped him apart for, his argument is very weak at best. He goes into zero detail, and where he does, it says things like "likely to increase CO2 consumption"? Seriously?
  - jamescostian 12y ago
    Do you have another explanation which hasn't been torn apart by Hacker News commentators already? As someone who would like to avoid going to the trouble to implement HTTP2, I'm not being sarcastic - I truly want to know why HTTP2 is so bad, and I want to read it from someone who backs up their words with cold-hard facts

logicallee 12y ago

this seems nice, pretty conservative. https://tools.ietf.org/html/draft-ietf-httpbis-http2-17 https://tools.ietf.org/html/draft-ietf-httpbis-http2-17 " Abstract This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. " all these changes seem good without a large change, just an improved user experience. (the Introduction section is also good - "HTTP/2 addresses these issues by defining an optimized mapping of HTTP's semantics to an underlying connection", I'd quote more but why not click through the link at the top of this comment. basically just some compression of headers, none of the funky stuff to keep connections alive for server push, prioritizing important requests, etc. all without changing semantics much - great.)

thomasfoster96 12y ago

I know I'm apparently not meant to be, but I'm genuinely keen to start using HTTP/2. If you've been following some of the things being done in HTML recently (rel=subresource, rel=dns-prefetch), I think it's starting to become a little obvious that for most people HTTP is the bottleneck. HTTP/2 seems to be a good, solid step forwards. If it's not perfect, well, it doesn't have to be; 2 isn't the last number.

deleted 12y ago
[deleted]
Practicality 12y ago
Agreed. I can't wait to start using it. Speed is a very important feature.

bgentry 12y ago

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

bgentry 12y ago
If anyone wants to learn more about optimizing for HTTP/2, unwinding HTTP/1.1 hacks, and strategies to optimize for both versions at the same time, Ilya Grigorik's "High Performance Browser Networking" is an excellent resource: http://chimera.labs.oreilly.com/books/1230000000545/ch13.html#_removing_1_x_optimizations http://chimera.labs.oreilly.com/books/1230000000545/ch13.htm...
- colin_jack 12y ago
  Couldn't agree more, its also one of the best written tech books I've ever read.
- hueving 12y ago
  If it requires a book to optimize for HTTP2, doesn't that counter your comment's parent's point? It's supposed to be simple.
  - rogeryu 12y ago
    Simple to use doesn't mean simple to create. Even a simple and small code base doesn't mean the think-process preceding the actual programming was simple.
  - exogen 12y ago
    One can write a book about literally anything. But besides that, it already "required" a book – at least two of them in fact, both published before Google even announced SPDY: "High Performance Web Sites" [1] in 2007 and its sequel "Even Faster Web Sites" [2] in 2009, both by Steve Souders. What are they about? Essentially, optimizing your HTTP responses for the ways in which actual web browsers make HTTP requests. Any web performance analysis tool worth using (like YSlow and PageSpeed – both of which Steve Souders was involved in btw) recommended the practices outlined in those books. So, no. I don't think a new book with updated practices says anything about the protocol. The optimization tips from this book will simply become widespread common knowledge the same way they did in the past. [1] http://shop.oreilly.com/product/9780596529307.do http://shop.oreilly.com/product/9780596529307.do [2] http://shop.oreilly.com/product/9780596522315.do http://shop.oreilly.com/product/9780596522315.do

deleted 12y ago

[deleted]

tropicalmug 12y ago

I wish instead of a protocol improvement that focused solely on network resources, the next version will also include improvements for users such as encryption by default and doing away with cookies.

numbsafari 12y ago
You can begin today to do away with cookies on your own sites and services. Start implementing richer clients and leveraging Open ID Connect and OAuth2. Cookies solve real use case problems. Unless we all start building and experiencing and improving the alternatives, progress won't be made. That said, good luck on getting rid of cookies all together.
- ecthiender 12y ago
  Excuse my ignorance, but how can I do session management without using cookies? I tried searching on the net, but it doesn't seem to give any concrete/valid results. Can you give me any pointers? Edit: I do use OAuth2.0 on my services and use Mozilla Persona to manage user logins, but I am not clear how can I keep sessions between requests if I don't use cookies.
  - MichaelGG 12y ago
    HTML5 has local storage, so you can put auth tokens in there and only send them when you need them, versus on every request.
    - stephenr 12y ago
      So rather than just using cookies effectively, you can make your application absolutely dependant on both JavaScrip and XHR?
      - omeid2 12y ago
        "Applications" on the web are inherently dependant on JavaScript and most often XHR too, but I do agree that using Local Storage has little to no advantage over Cookies.

bantic 12y ago

I read Daniel Stenberg's (he is a maintainer of curl, I think?) "http2 explained" pdf the other day, and it's by far the best comprehensive explanation of http2 that I have seen. Well worth a read if you're curious what's coming with http2. http://daniel.haxx.se/http2/ http://daniel.haxx.se/http2/

pgl 12y ago
Hacker News thread: https://news.ycombinator.com/item?id=9038613 https://news.ycombinator.com/item?id=9038613

RunningWild 12y ago

Another year, another wheel reinvented.

Intermernet 12y ago
I know you're being somewhat facetious, but have you considered how much the wheel has actually been reinvented? The first wheels were probably logs under rocks. Then axles got developed, then spokes, then tyres etc. Everything from the gyroscope to the LHC can attribute it's beginnings to the humble wheel. Reinvention is, if not always good, always admirable.
- RunningWild 12y ago
  Up to a point, I agree. Beyond that point it becomes churn and reinvention for the sake of itself.

cm2187 12y ago

Stupid question: would you rather have server push serving static content from the application server or a CDN for the static assets? If a CDN, how can server push be leveraged when the assets are not related to each others (and the server can't tell in which order they will be requested).

youngtaff 12y ago
Where sites serve the base page through a CDN, then the CDN has the potential to start making intelligent decisions on what should be pushed. As the simplest level this might be just the CSS, and JS in the <head> but obviously as different UA's behave differently there's scope for much granular optimisations.
- cm2187 12y ago
  That's the easy, but relatively rare scenario. Today most content is dynamic. Naively, it looks to me that server push will mostly be an improvement for small websites that do not use a CDN, but I can't see how it can coexist with a CDN. Or it would require a new syntax, where the html tells the browser to start connecting to the CDN with this particular URL, which contains a token, and should be downloaded first which would tell the CDN that a particular list of assets will be needed for that page, and then the CDN will use server push to send these static assets. Alternatively the CDN would become a proxy for the underlying html page, which would still be generated by the application server. That would probably be simpler.
  - youngtaff 12y ago
    CDNs aren't limited to just static content, it's quite common for large dynamic sites to deliver their base pages though CDNs. They can use features like ESI to assemble the final page on the edge from static and dynamic parts, or they can just act as a proxy to the origin with the dynamic page generated there. Even when the CDN is just acting as a proxy back to the origin there can be performance advantages e.g. lower latency TCP and TLS negotiation between edge to client, and permanent connection between edge and origin i.e. single TCP negotiation for all clients, larger congestion windows leading to higher throughput. In short CDNs aren't just for static content!

blueskin_ 12y ago

Did that anti-encryption backdoor get put in in the end or not? News reporting on it went quiet a while back...

theallan 12y ago

Does anyone have any information about HTTP/2 development in Apache? Searching the bug list I don't immediately see anything and the only thing I can find from a Google search is a mailing list entry with someone asking about http/2 development and being told that it isn't really being worked on [1] [1] http://mail-archives.apache.org/mod_mbox/httpd-dev/201408.mbox/%3CCALK=YjONaJzKsYouzrYJrhT=ZXW6oHbZCgtBH9nfi5wuP=qwDw@mail.gmail.com%3E http://mail-archives.apache.org/mod_mbox/httpd-dev/201408.mb...

scorpwarp23 12y ago

I'd really like to know what this means in the context of MeteorJS - particularly how the HTTP Push feature will affect MeteorJS in the long run. Does it make MeteorJS redundant?

scorpwarp23 12y ago

I'd really like to know what this means in the context of MeteorJS - particularly how the HTTP Push feature will affect MeteorJS in the long run. Does it make MeteorJS redundant?

orthecreedence 12y ago

Question: I originally heard HTTP/2 would force TLS and have it baked into the protocol. Is this still the case? If so, is this going to be strictly enforced? I think it's a really terrible idea to melt a protocol and a transport together. Or am I misunderstanding how it works?

garraeth 12y ago
This says yes for Chrome and FF but no such requirement for cURL or IE: http://daniel.haxx.se/http2/ http://daniel.haxx.se/http2/ How accurate it is, I'm not sure.