5 ms·

A problem which previously people solved by opening a bunch of connections and even using different subdomains so they could bypass browser limits I suppose th

A problem which previously people solved by opening a bunch of connections and even using different subdomains so they could bypass browser limits I suppose that's one way of putting it. Currently, the home page at www.google.com wants to do twenty-five requests in order to show me an interface consisting of a text input and two buttons. Google decided to fundamentally redesign HTTP to accommodate their own inability to impose any kind of discipline on their programmers. I don't see this as a good thing.

dagenix 8y ago
> Google decided to fundamentally redesign HTTP to accommodate their own inability to impose any kind of discipline on their programmers 1) That is a ridiculous statement with absolutely no evidence to back it up. 2) The number of requests that Googles homepage does in order to load has _nothing at all_ to do with whether or not solving head of line blocking problems for the rest of the web is a good thing.
- ubernostrum 8y ago
  The number of requests that Googles homepage does in order to load has _nothing at all_ to do with It has a lot to do with the desire to work around limits on the number of in-flight connections allowed to a single host, which is one of the primary things HTTP/2 is designed for.
  - dagenix 8y ago
    Google has spent at least 6 years (and counting) working on SPDY / HTTP2 / QUIC on design, experimentation, implementation, and specification tasks. This is low-level, complex work that requires a combination of experience and talent. This is expensive work - and there was never any guarantee it would pan out. I think it's unreasonable to assert, without evidence, that they did all that just because parts of their organization are incompetent and they refuse to fix it or that the problems they are trying to address have some sort of trivial solution. It's also pretty unreasonable to point at www.google.com and say that it makes too many requests and it could be trivially fixed to use fewer. But, let's assume that the problem you identify actually is the case: Google is a huge, cash rich organization - if they can't figure out how to enact the change you suggest, how could any other organization? And if HTTP/2 and QUIC (HTTP3) solve this problem for Google, and since they are making it an open standard, also for other organizations, why is that a bad thing?
- PavlovsCat 8y ago
  > That is a ridiculous statement with absolutely no evidence to back it up. Press Ctrl+U on any Google page. > The number of requests that Googles homepage does in order to load has _nothing at all_ to do with whether or not solving head of line blocking problems for the rest of the web is a good thing. No, but it's evidence you claim doesn't exist.
  - dagenix 8y ago
    Google's home page doing 25 requests does not prove that Google spent the last 6 years and millions of dollars developing new protocols because they unable to reduce the number of requests.
    - PavlovsCat 8y ago
      Not the requests per se, but the HTML source. But you're right, it says nothing about the reasons for developing new protocols, also not anything about inability, it could also be unwillingness. It takes large team to produce a pages so bad as the Google landing page, blogger etc. For me, just about anything Google I looked at is to a well crafted website what elevator music played with a 1000 man orchestra is to someone with a guitar singing a really good song. The scale and the available resources makes the result worse to me, not better.
- josteink 8y ago
  > That is a ridiculous statement with absolutely no evidence to back it up. I’d hate to bring it up but here goes: SPDY was designed specifically to load the Google homepage quickly on typical American DSL MTU configuration, even with all that JavaScript tracking enabled. Turned on it’s head: SPDY was designed to make google’s wide tracking of end-users impact page-load times as little impact as possible, to avoid it being a cause of end-user dissatisfaction. SPDY was extremely tailored to a very niche need which first and foremost serves Google.
  - dagenix 8y ago
    The thread here is about HTTP3 - ie, HTTP2 over QUIC. HTTP3 has features that are going to benefit high latency, high loss connections a lot. Things such as speeding TLS negotiation, and only having to do it for one connection; better handling of packet loss; forward error correction (if it works). I see you don't cite any evidence that SPDY was miopically designed for American DSL connections, but regardless of that, HTTP3 is going to benefit a wife range of connection types.

dagenix 8y ago

> Google decided to fundamentally redesign HTTP to accommodate their own inability to impose any kind of discipline on their programmers 1) That is a ridiculous statement with absolutely no evidence to back it up. 2) The number of requests that Googles homepage does in order to load has _nothing at all_ to do with whether or not solving head of line blocking problems for the rest of the web is a good thing.

ubernostrum 8y ago
The number of requests that Googles homepage does in order to load has _nothing at all_ to do with It has a lot to do with the desire to work around limits on the number of in-flight connections allowed to a single host, which is one of the primary things HTTP/2 is designed for.
- dagenix 8y ago
  Google has spent at least 6 years (and counting) working on SPDY / HTTP2 / QUIC on design, experimentation, implementation, and specification tasks. This is low-level, complex work that requires a combination of experience and talent. This is expensive work - and there was never any guarantee it would pan out. I think it's unreasonable to assert, without evidence, that they did all that just because parts of their organization are incompetent and they refuse to fix it or that the problems they are trying to address have some sort of trivial solution. It's also pretty unreasonable to point at www.google.com and say that it makes too many requests and it could be trivially fixed to use fewer. But, let's assume that the problem you identify actually is the case: Google is a huge, cash rich organization - if they can't figure out how to enact the change you suggest, how could any other organization? And if HTTP/2 and QUIC (HTTP3) solve this problem for Google, and since they are making it an open standard, also for other organizations, why is that a bad thing?
PavlovsCat 8y ago
> That is a ridiculous statement with absolutely no evidence to back it up. Press Ctrl+U on any Google page. > The number of requests that Googles homepage does in order to load has _nothing at all_ to do with whether or not solving head of line blocking problems for the rest of the web is a good thing. No, but it's evidence you claim doesn't exist.
- dagenix 8y ago
  Google's home page doing 25 requests does not prove that Google spent the last 6 years and millions of dollars developing new protocols because they unable to reduce the number of requests.
  - PavlovsCat 8y ago
    Not the requests per se, but the HTML source. But you're right, it says nothing about the reasons for developing new protocols, also not anything about inability, it could also be unwillingness. It takes large team to produce a pages so bad as the Google landing page, blogger etc. For me, just about anything Google I looked at is to a well crafted website what elevator music played with a 1000 man orchestra is to someone with a guitar singing a really good song. The scale and the available resources makes the result worse to me, not better.
josteink 8y ago
> That is a ridiculous statement with absolutely no evidence to back it up. I’d hate to bring it up but here goes: SPDY was designed specifically to load the Google homepage quickly on typical American DSL MTU configuration, even with all that JavaScript tracking enabled. Turned on it’s head: SPDY was designed to make google’s wide tracking of end-users impact page-load times as little impact as possible, to avoid it being a cause of end-user dissatisfaction. SPDY was extremely tailored to a very niche need which first and foremost serves Google.
- dagenix 8y ago
  The thread here is about HTTP3 - ie, HTTP2 over QUIC. HTTP3 has features that are going to benefit high latency, high loss connections a lot. Things such as speeding TLS negotiation, and only having to do it for one connection; better handling of packet loss; forward error correction (if it works). I see you don't cite any evidence that SPDY was miopically designed for American DSL connections, but regardless of that, HTTP3 is going to benefit a wife range of connection types.