You might find this interesting: https://ma.ttias.be/architecting-websites-http2-era/#comment-10935

(PUSH_PROMISE frame)

Glen.

On 2015/04/16 22:43, John Barton wrote:


On Thu, Apr 16, 2015 at 1:22 PM, Domenic Denicola <[email protected] <mailto:[email protected]>> wrote:

    From: John Barton [mailto:[email protected]
    <mailto:[email protected]>]

    > But the push scenario in your first paragraph would not use the
    cache either.

    Yeah, that's what I was alluding to with the "most naïve" comment.

    >  one or the other has to send its information at the outset of a
    import request, or

    One way of doing this I came up with off the top of my head is to
    add some kind of "dependency graph version" or hash to the query
    string. I.e. <script type="module" src="entry.js?1234"></script>.
    The server can then assume that the client has in its cache
    version 1234 of the dependency graph, and can push the incremental
    updates since then (i.e. added or modified files). If parts of the
    cache were evicted, so that the versioning signal is not entirely
    accurate, then the penalty is not so bad, as you just fall back to
    the normal loading process for the evicted subset.

    But I feel pretty silly speculating here as I'm not an expert on
    HTTP/2 techniques, and there are probably other methods that are
    better in various ways.


Perhaps, but I feel the issue is more fundamental. HTTP/2 shares statelessness with HTTP/1. It follows that the state of the client must be sent to the server or vice versa. HTTP/2 can make that process much faster but it's not going to know what state to send without instructions from clients or from servers. We can all make up those instructions one at a time and in our own unique ways or the module experts can come up with a good solution for the common cases. I'm hoping for the latter ;-)

jjb



_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to