{"action":"created","issue":{"url":"https://api.github.com/repos/mnot/I-D/issues/167","repository_url":"https://api.github.com/repos/mnot/I-D","labels_url":"https://api.github.com/repos/mnot/I-D/issues/167/labels{/name}","comments_url":"https://api.github.com/repos/mnot/I-D/issues/167/comments","events_url":"https://api.github.com/repos/mnot/I-D/issues/167/events","html_url":"https://github.com/mnot/I-D/pull/167","id":127145939,"number":167,"title":"use a HTTP header to convey the digest","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/mnot/I-D/labels/h2-cache-digest","name":"h2-cache-digest","color":"fef2c0"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":21,"created_at":"2016-01-18T03:10:46Z","updated_at":"2016-03-11T06:26:00Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/mnot/I-D/pulls/167","html_url":"https://github.com/mnot/I-D/pull/167","diff_url":"https://github.com/mnot/I-D/pull/167.diff","patch_url":"https://github.com/mnot/I-D/pull/167.patch"},"body":"This PR changes the conveyer of the cache digest from a HTTP/2 frame to a HTTP request header.\r\n\r\nThere are several merits in doing so.  By defining it as a header,\r\n\r\n* a cache-digest can be sent by ServiceWorker\r\n* a cache-digest can easily be transferred to application servers over HTTP/1\r\n* client connecting through an cache-digest-unaware proxy can benefit from push\r\n\r\nThe downside had been considered that including a cache-digest in every HTTP request might consume too much upstream bandwidth (when compared to using a HTTP/2 frame), but I have concluded that by sending multiple cache-digest headers we can earn effective compression by HPACK so that the overhead may be negligible.\r\n\r\nFor example, a client can send in the first HTTP request after establishing an HTTP/2 connection a cache-digest header containing the entire digest:\r\n```\r\ncache-digest: fresh=ABC...xyz    # entire cache digest\r\n```\r\nand in the following HTTP requests, send the same big header (which will be compressed to 1 to 2 bytes by HPACK) and a second header containing a small delta since the first request.\r\n```\r\ncache-digest: fresh=ABC...xyz    # entire cache digest\r\ncache-digest: fresh=0uec         # small delta\r\n```\r\n\r\nThe ABNF has been generalized to use set of name-value pairs in order to give room for future extensions.\r\n\r\nSome relevant mails regarding the topic:\r\nhttps://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0076.html\r\nhttps://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0081.html\r\nhttps://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0095.html\r\nhttps://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0096.html\r\nhttps://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0120.html"},"comment":{"url":"https://api.github.com/repos/mnot/I-D/issues/comments/195215720","html_url":"https://github.com/mnot/I-D/pull/167#issuecomment-195215720","issue_url":"https://api.github.com/repos/mnot/I-D/issues/167","id":195215720,"user":{"login":"mnot","id":74384,"avatar_url":"https://avatars.githubusercontent.com/u/74384?v=3","gravatar_id":"","url":"https://api.github.com/users/mnot","html_url":"https://github.com/mnot","followers_url":"https://api.github.com/users/mnot/followers","following_url":"https://api.github.com/users/mnot/following{/other_user}","gists_url":"https://api.github.com/users/mnot/gists{/gist_id}","starred_url":"https://api.github.com/users/mnot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mnot/subscriptions","organizations_url":"https://api.github.com/users/mnot/orgs","repos_url":"https://api.github.com/users/mnot/repos","events_url":"https://api.github.com/users/mnot/events{/privacy}","received_events_url":"https://api.github.com/users/mnot/received_events","type":"User","site_admin":false},"created_at":"2016-03-11T06:26:00Z","updated_at":"2016-03-11T06:26:00Z","body":"Thinking about this, one thing that strikes me is that the use cases for the frame vs. the header are subtly different.\r\n\r\nI suspect the frame is always (or nearly always) going to be generated by the HTTP cache of the client, not application code, and the header is going to be generated by application code, not the HTTP cache.\r\n\r\nThe HTTP cache has a definitive view of all responses it holds for the origin, and it doesn't have any concept of application boundaries within the origin. Therefore, I think that the `path` parameter doesn't make much sense for the frame type, and it's probably safe to always make the origin that of the associated stream. I'm not necessarily against defining these parameters for the frame, but I suspect they won't get used much.\r\n\r\nOn the other hand, the header is going to be used by ServiceWorker, and that has a definite \"footprint\" on the origin that is useful to describe with `path`. \r\n\r\nSending an incomplete digest is very important for the HTTP cache / frame use case, because the client wants to send enough digest to be useful, but not so much as to require the server to pause before starting to push, because it's still consuming the digest (remembering that if the connection is new, filling the initial congestion window is a risk for a cache holding even ~700 responses for the origin). Remember, the HTTP cache can't make rational decisions about how to segment up the origin into paths.\r\n\r\nIt's not nearly as important for the service worker case, since the SW has application knowledge, and is not (usually) handling the complete origin."}}