To optimize the responsiveness of a website, it is desirable to push assets (e.g. CSS and/or JavaScript files) that block the page rendering process when and only when such files do not already exist within the client's cache. However, the specifications do not define a way to determine whether if a resource is already cached.
This issue proposes of using a cookie containing a probablistic data set as an approximation for determining the cache state of the client, and using it for restricting server-push - i.e. only push the asset files that are unlikely to be cached.
Basic Design
- use a single cookie that stores a Golomb coded set as to mark if the assets are cached
- key for the set will be calculated as
key(filename)=sha1(filename + etag(filename))
- for each HTTP2 connection, the server maintains the value of the set
- the set is initialized as empty
- when receiving the cookie, the value of the set is set the the received value
- when starting to send a response, for that response mark the set using a key calculated using the rule above, and send
set-cookie header containing the value of the set
- when application logic triggers a server-push, check if the to-be-pushed content is marked within the set, and if marked, ignore the trigger. If not, push the content to the client at the same time updating the value of the set using the rule above.
- server may also maintain a set that maps all the existing files, and use the set to clear the keys of the incoming set that do not exist (i.e. means that the corresponding file has either been removed or updated), before copying the value to the internally maintained value
By applying this design for restricting server push, the only drawback of using server push will become when the cookie on the client expires before the asset cached in the client's cache expires. In other words, the design will work effectively if such case is unlikely.
Notes
Since HTTP2 multiplexes the HTTP requests over a single stream, it has become possible for the web server to expect in which order the client receives the responses (i.e. we can safely say that: if the client has received the headers of response A, then it must have received the headers of response B that has been sent prior to A). The design takes advantage of the property.
A good read on Golomb coded set is this blogpost. The only issue the doc has is how M of Golomb coded is calculated; theoretically it should use median instead mean value.
To optimize the responsiveness of a website, it is desirable to push assets (e.g. CSS and/or JavaScript files) that block the page rendering process when and only when such files do not already exist within the client's cache. However, the specifications do not define a way to determine whether if a resource is already cached.
This issue proposes of using a cookie containing a probablistic data set as an approximation for determining the cache state of the client, and using it for restricting server-push - i.e. only push the asset files that are unlikely to be cached.
Basic Design
key(filename)=sha1(filename + etag(filename))set-cookieheader containing the value of the setBy applying this design for restricting server push, the only drawback of using server push will become when the cookie on the client expires before the asset cached in the client's cache expires. In other words, the design will work effectively if such case is unlikely.
Notes
Since HTTP2 multiplexes the HTTP requests over a single stream, it has become possible for the web server to expect in which order the client receives the responses (i.e. we can safely say that: if the client has received the headers of response A, then it must have received the headers of response B that has been sent prior to A). The design takes advantage of the property.
A good read on Golomb coded set is this blogpost. The only issue the doc has is how M of Golomb coded is calculated; theoretically it should use median instead mean value.