{"action":"created","issue":{"url":"https://api.github.com/repos/h2o/h2o/issues/447","labels_url":"https://api.github.com/repos/h2o/h2o/issues/447/labels{/name}","comments_url":"https://api.github.com/repos/h2o/h2o/issues/447/comments","events_url":"https://api.github.com/repos/h2o/h2o/issues/447/events","html_url":"https://github.com/h2o/h2o/issues/447","id":101414361,"number":447,"title":"push cache validator","user":{"login":"kazuho","id":41567,"avatar_url":"https://avatars.githubusercontent.com/u/41567?v=3","gravatar_id":"","url":"https://api.github.com/users/kazuho","html_url":"https://github.com/kazuho","followers_url":"https://api.github.com/users/kazuho/followers","following_url":"https://api.github.com/users/kazuho/following{/other_user}","gists_url":"https://api.github.com/users/kazuho/gists{/gist_id}","starred_url":"https://api.github.com/users/kazuho/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kazuho/subscriptions","organizations_url":"https://api.github.com/users/kazuho/orgs","repos_url":"https://api.github.com/users/kazuho/repos","events_url":"https://api.github.com/users/kazuho/events{/privacy}","received_events_url":"https://api.github.com/users/kazuho/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/h2o/h2o/labels/enhancement","name":"enhancement","color":"84b6eb"},{"url":"https://api.github.com/repos/h2o/h2o/labels/http2","name":"http2","color":"5319e7"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-08-17T12:55:08Z","updated_at":"2015-08-31T19:12:40Z","closed_at":null,"body":"Even if we do not want to push the _contents_ of every asset file (if it is not cached, see #421), pushing cache validators (i.e. notify the client that a file it _might_ have cached need not be revalidated) is still a good thing, since it would nullify the RTT required for revalidation.\r\n\r\nIn H2O, we are considering of implementing following method.\r\n\r\n* when receiving a `GET` request against an asset file without `etag` query parameter, temporary redirect the request to the same asset file with `etag` query parameter added, with the value of the parameter being the etag of the asset file\r\n * e.g. request to `/assets/foo.js` is redirected to `/assets/foo.js?etag=xxxxxxxx`\r\n* if the `GET` request against the asset file contained the correct `etag` query parameter, respond with a 200 response containing the asset file with `expires` header set to a time in very far future\r\n* for every `link: rel=preload` header (that do not trigger cache-aware server push), trigger a server-push that pushes the temporary redirect described above\r\n\r\nBy implementing this approach, web browsers can identify zero-RTT whether or not a valid entry exists in its cache.  They would only spend 1-RTT or more if the asset does not exist in its cache.\r\n\r\nNotes:\r\n* [this thread](https://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0800.html) discusses a different approach, however it is unlikely that it would work 100% correctly\r\n* in HTTP/1, the best practice for nullifying the time spent for cache revalidation was to add query parameters to the asset files and at the server side serve such files with `expires` headers.  The problem with the approach is that it is hard to maintain; to avoid unnecessary transfers you need to set different tags (i.e. query parameters) to every asset file, and only update the tags of the files that have actually been modified (which in fact is rarely done).  With the proposed method, web developers no longer need to take care of such tags."},"comment":{"url":"https://api.github.com/repos/h2o/h2o/issues/comments/136471565","html_url":"https://github.com/h2o/h2o/issues/447#issuecomment-136471565","issue_url":"https://api.github.com/repos/h2o/h2o/issues/447","id":136471565,"user":{"login":"kazuho","id":41567,"avatar_url":"https://avatars.githubusercontent.com/u/41567?v=3","gravatar_id":"","url":"https://api.github.com/users/kazuho","html_url":"https://github.com/kazuho","followers_url":"https://api.github.com/users/kazuho/followers","following_url":"https://api.github.com/users/kazuho/following{/other_user}","gists_url":"https://api.github.com/users/kazuho/gists{/gist_id}","starred_url":"https://api.github.com/users/kazuho/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kazuho/subscriptions","organizations_url":"https://api.github.com/users/kazuho/orgs","repos_url":"https://api.github.com/users/kazuho/repos","events_url":"https://api.github.com/users/kazuho/events{/privacy}","received_events_url":"https://api.github.com/users/kazuho/received_events","type":"User","site_admin":false},"created_at":"2015-08-31T19:12:40Z","updated_at":"2015-08-31T19:12:40Z","body":"@igrigorik @jeffkaufman Sorry for the lack of explanation in detail.\r\n\r\nYes, what I am propsoing here is [@jeffkaufman's last comment](https://github.com/h2o/h2o/issues/447#issuecomment-136453402).\r\n\r\nI agree that it is kind of ugly, but it does not rely on the vague (possibly non-defined) behavior of 304 pushes, and it would work."}}