3 ms·

How is this different from rel="preload" in HTML to preload (css javascript ... ) Ex: https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types/preload#what_

by skyde 4y ago

How is this different from rel="preload" in HTML to preload (css javascript ... ) Ex: https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types/preload#what_types_of_content_can_be_preloaded https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types... The webserver could just parse the HTML and send http push for each dependency! What was the problem with doing this? To me this seem very similar to "open document format" are storing html with all its dependency in a ZIP package. So with HTTP/2 push you just push the whole package and the client tell the server if it already have some of the files.

coder543 4y ago
> The webserver could just parse the HTML and send http push for each dependency! What was the problem with doing this? Well… the client knows which resources are already in its cache. The server does not. You just suggested that the server should always send resources that client almost certainly already had cached, which is wasteful for everyone involved. > So with HTTP/2 push you just push the whole package and the client tell the server if it already have some of the files. That doesn’t make sense. Once the files have been pushed, the bandwidth and time has already been wasted. The client doesn’t get to tell the server anything in that scenario.
- 0x457 4y ago
  I guess the client could tell server that "I already have that file in cache", but it's still weird, might require another round-trip (server asking if client needs this file).
- skyde 4y ago
  a push is an HTTP2 stream. the stream header contain everything the client need to know if it already have that file. If it does already have that file, client simply close the stream it doesn't need to download the file or send request to server to say it doesn't need the file.
  - coder543 4y ago
    Even then, the average case would still be worse because the server would be sending all these unnecessary stream headers and forcing the client to send so many unnecessary RST_STREAM frames back. Each PUSH_PROMISE is supposed to contain the full set of headers for each resource. I guess I hadn’t realized that clients could RST_STREAM on these pushes, but it doesn’t change the outcome here. What you describe isn’t a win for anyone except a client with a cold cache, and then they start losing immediately after that. That’s why it isn’t done. That’s why HTTP/2 Push is going away.
    - Matthias247 4y ago
      Even if a client does a RST_STREAM, the origin server might already have done a lot of additional work (e.g. request the pushed file from an upstream if it's a proxy/CDN), and probably stuffed min(TCP_SEND_BUFFER_SIZE, STREAM_FLOW_CONTRO_WINDOW) of data into the stream. Which then also means all of that work might get billed if the server is a managed service. It's really quite some waste of resources compared to the client sending an additional request (which might even be a conditional request).
      - coder543 4y ago
        Yeah, and unless I’m wrong, this also means the TTFB could be significantly higher, since I think the PUSH_PROMISE frames need to come before the main content. Doing that at least requires gathering up the information on those objects, which takes time.
        skyde 4y ago
        you are 100% right :-( The spec say "The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to sending any frames that reference the promised responses. This avoids a race where clients issue requests prior to receiving any PUSH_PROMISE frames."
        Matthias247 4y ago

by skyde 4y ago

coder543 4y ago

> The webserver could just parse the HTML and send http push for each dependency! What was the problem with doing this? Well… the client knows which resources are already in its cache. The server does not. You just suggested that the server should always send resources that client almost certainly already had cached, which is wasteful for everyone involved. > So with HTTP/2 push you just push the whole package and the client tell the server if it already have some of the files. That doesn’t make sense. Once the files have been pushed, the bandwidth and time has already been wasted. The client doesn’t get to tell the server anything in that scenario.

0x457 4y ago
I guess the client could tell server that "I already have that file in cache", but it's still weird, might require another round-trip (server asking if client needs this file).
skyde 4y ago
a push is an HTTP2 stream. the stream header contain everything the client need to know if it already have that file. If it does already have that file, client simply close the stream it doesn't need to download the file or send request to server to say it doesn't need the file.
- coder543 4y ago
  Even then, the average case would still be worse because the server would be sending all these unnecessary stream headers and forcing the client to send so many unnecessary RST_STREAM frames back. Each PUSH_PROMISE is supposed to contain the full set of headers for each resource. I guess I hadn’t realized that clients could RST_STREAM on these pushes, but it doesn’t change the outcome here. What you describe isn’t a win for anyone except a client with a cold cache, and then they start losing immediately after that. That’s why it isn’t done. That’s why HTTP/2 Push is going away.
  - Matthias247 4y ago
    Even if a client does a RST_STREAM, the origin server might already have done a lot of additional work (e.g. request the pushed file from an upstream if it's a proxy/CDN), and probably stuffed min(TCP_SEND_BUFFER_SIZE, STREAM_FLOW_CONTRO_WINDOW) of data into the stream. Which then also means all of that work might get billed if the server is a managed service. It's really quite some waste of resources compared to the client sending an additional request (which might even be a conditional request).
    - coder543 4y ago
      Yeah, and unless I’m wrong, this also means the TTFB could be significantly higher, since I think the PUSH_PROMISE frames need to come before the main content. Doing that at least requires gathering up the information on those objects, which takes time.
      - skyde 4y ago
        you are 100% right :-( The spec say "The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to sending any frames that reference the promised responses. This avoids a race where clients issue requests prior to receiving any PUSH_PROMISE frames."
        Matthias247 4y ago