11 ms·

HTTP/2 Is Done

437 points by stephenjudkins 12y ago

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
      - lazyloop 12y ago
        This for example happened in the HTTP working group earlier today, the whole thing was rushed and the known flaws just keep adding up. https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0475.html https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar...
        asuffield 12y ago
        I followed the thread a little further, and the response seemed reasonable: experiments were run on this idea, it didn't seem to help, and nobody (including phk) has offered any further evidence to the contrary since then. I think you need to expand a little more on why you feel this is a "known flaw".
        bsdetector 12y ago
        A 60 page document to explain how to compress text name/value pairs that are mostly unchanged between requests is "reasonable"? A static compression table with proxy authentication fields in it, as if the network between your browser and LAN proxy is somehow the bottleneck, is reasonable? This is a most over-engineered protocol, one where nobody knows how tables were constructed or from what data and nobody can quantify what the benefits its features will really be. For instance how much is saved by using a huffman encoding instead of a simple LZ encoding or simple store/recall or not compressing it? Nobody knows! Google did some magic research in private and decided on the most complicated compression method, so therefore HTTP/2 must use it. This HTTP/2 process is insane.
        frankzinger 12y ago
  - megaman821 12y ago
    It is not a bad protocol for what is in there, it is bad for what is not. It seems like it was built for the big players to eek out 5% more performance. How about the average website? What is in there help standardize authentication? What is in there to help protect privacy? In the end it looks more HTTP 1.2, with header compression being the only new feature. The rest of what makes up HTTP 2 is basically implementing a new transport layer protocol at the application level.
    - tptacek 12y ago
      "Standardize authentication"?
      - megaman821 12y ago
        Well Basic Auth exists now, but it is unusable for most sites due to several well-documented shortcomings. Surely something could be done to improve upon it.
        Kalium 12y ago
        Like kicking it up to the application layer?
        tveita 12y ago
        You can add new authentication methods by defining the format of the authorization/authentication headers. OAuth 2 does it. The only thing you need is buy-in from application authors.
        megaman821 12y ago
        This is mostly true but browsers treat Basic Auth special. To use Authorization Bearer headers you have to use JavaScript and perhaps localstorage. When using Basic Auth the browser caches your credentials and allows you to be authenticated without cookies and without JavaScript code. The only way you can use OAuth header authorization today is with JavaScript apps, Basic Auth works with normal server side apps.
  - jimktrains2 12y ago
    Because it doesn't solve any problems except page loading speed. There are other things that people care about and the added complexity of implementing Layer 4 in Layer 7 make it even more of a monstrosity. I put this in another comment in the above: * Better authentication * More secure caching * Improved ability to download large files * Better methods to find alternate downloads locations * Making each request contain less information about the sender * Improved Metadata I brain-dump a bit here: https://github.com/jimktrains/http_ng https://github.com/jimktrains/http_ng
    - lazyloop 12y ago
      How is it that sensible comments like this keep getting downvoted?
      - jimktrains2 12y ago
        I just wish people would actually discuss their opposition to any statement I made rather than just downvoting, but so it is.
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.
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

deleted 12y ago

[deleted]

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
    - lazyloop 12y ago
      This for example happened in the HTTP working group earlier today, the whole thing was rushed and the known flaws just keep adding up. https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0475.html https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar...
      - asuffield 12y ago
        I followed the thread a little further, and the response seemed reasonable: experiments were run on this idea, it didn't seem to help, and nobody (including phk) has offered any further evidence to the contrary since then. I think you need to expand a little more on why you feel this is a "known flaw".
        bsdetector 12y ago
        A 60 page document to explain how to compress text name/value pairs that are mostly unchanged between requests is "reasonable"? A static compression table with proxy authentication fields in it, as if the network between your browser and LAN proxy is somehow the bottleneck, is reasonable? This is a most over-engineered protocol, one where nobody knows how tables were constructed or from what data and nobody can quantify what the benefits its features will really be. For instance how much is saved by using a huffman encoding instead of a simple LZ encoding or simple store/recall or not compressing it? Nobody knows! Google did some magic research in private and decided on the most complicated compression method, so therefore HTTP/2 must use it. This HTTP/2 process is insane.
        frankzinger 12y ago
- megaman821 12y ago
  It is not a bad protocol for what is in there, it is bad for what is not. It seems like it was built for the big players to eek out 5% more performance. How about the average website? What is in there help standardize authentication? What is in there to help protect privacy? In the end it looks more HTTP 1.2, with header compression being the only new feature. The rest of what makes up HTTP 2 is basically implementing a new transport layer protocol at the application level.
  - tptacek 12y ago
    "Standardize authentication"?
    - megaman821 12y ago
      Well Basic Auth exists now, but it is unusable for most sites due to several well-documented shortcomings. Surely something could be done to improve upon it.
      - Kalium 12y ago
        Like kicking it up to the application layer?
      - tveita 12y ago
        You can add new authentication methods by defining the format of the authorization/authentication headers. OAuth 2 does it. The only thing you need is buy-in from application authors.
        megaman821 12y ago
        This is mostly true but browsers treat Basic Auth special. To use Authorization Bearer headers you have to use JavaScript and perhaps localstorage. When using Basic Auth the browser caches your credentials and allows you to be authenticated without cookies and without JavaScript code. The only way you can use OAuth header authorization today is with JavaScript apps, Basic Auth works with normal server side apps.
- jimktrains2 12y ago
  Because it doesn't solve any problems except page loading speed. There are other things that people care about and the added complexity of implementing Layer 4 in Layer 7 make it even more of a monstrosity. I put this in another comment in the above: * Better authentication * More secure caching * Improved ability to download large files * Better methods to find alternate downloads locations * Making each request contain less information about the sender * Improved Metadata I brain-dump a bit here: https://github.com/jimktrains/http_ng https://github.com/jimktrains/http_ng
  - lazyloop 12y ago
    How is it that sensible comments like this keep getting downvoted?
    - jimktrains2 12y ago
      I just wish people would actually discuss their opposition to any statement I made rather than just downvoting, but so it is.

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.

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.