- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 13 Jul 2016 10:52:49 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>, asilvas@godaddy.com
First, I think that there is an interesting idea hidden in here. It could be that it's complementary to the more generic digests idea. However, I found it impossible to determine how this document is claiming to achieve its stated goals. None of the examples include header fields, which would have gone a long way to explaining this. The new header fields don't really say what each is used for. That leaves me guessing about how this fits together. Here's my best guess, though I have to confess that I can't connect this to what Section 4 says: On request N. A server provides a new header field with responses that create a secondary identifier for resources. I'm really guessing here, but I assume that unlike etag, this header field includes a value that is the same for a group of resources. On request >N. Clients include a new header field with requests that controls what is pushed. If it includes '*', then everything is pushed. If it includes 'no-push', then nothing is pushed. If it includes a list of these new push-asset-keys, then anything matching those keys is not pushed. Based on this, I'm fairly certain that I don't understand the proposal, because this design doesn't require both Push-Asset-Key and Push-Asset-Match header fields. I'm clearly missing something. I did start to look at the code, but without a better overview of what it aims to achieve, I'm afraid that I'm not going to get much from it.
Received on Wednesday, 13 July 2016 00:53:23 UTC