RE: draft-asilvas-http-push-assets-00 comments

[Mike Bishop <[e-mail]>]

This seems risky (and I'm presuming you mean "if no Server Push is performed").  The client assumes the resource is fresh if the server doesn't push it, even if it's showing as stale in the cache?  I'd prefer some form of positive signal, not only because it reduces the likelihood of implementation mistakes, but also because it lets the client get fresh lifetimes.  Pushing a 304 for the resource in cache seems cleaner, and still relatively cheap.

I think the fundamental new idea here is having the server proactively tag resources that it might push in the future, so the client can include only those resources in the data that it provides.

From: Aaron L. Silvas [mailto:[e-mail]]
Sent: Wednesday, July 13, 2016 9:25 AM
To: Martin Thomson <[e-mail]>; HTTP Working Group <[e-mail]>
Subject: Re: draft-asilvas-http-push-assets-00 comments


Thanks for the feedback, Martin. I agree the document needs work to better clarify things.



I'll attempt to address your comments here, in hopes of striking further conversation on the topic.



"Push-Assets" is the only request header; required only if the client wishes to enable the full HTTP/2 Push-Assets flow as outlined in the draft. If the server does not support/understand the header, it is benign. This allows the client to inform the server of its cache state, for push-enabled assets only (unlike Cache Digest HTTP/2 proposal which sends everything). This header includes the exact state of each of these resources, as if they were individually requested, and thus supports existing etag and last-modified headers. Not only will the server know what resources the client does and does not have, but it will also know which resources are simply out of date and must still be pushed. The server won't even need to send a 304 (Server Push) response for unmodified resources, as the server knows the state of the clients push-enabled assets, and the client can assume "no change" if Server Push is performed on the given resources. This effectively means that the server will only ever send what is missing or changed, no more, no less.



Example (requests only to keep length of email to a minimum):



  GET /page1

  Push-Assets: *



  GET /page2
  Push-Assets: md5(shared-resource1.js)=etag(123456)



"Push-Asset-Key" is an optional response header. It allows the server to "name" a resource, allowing it to renamed at a later time without worry of having to refetch unnecessarily. By default, the "key" of every resource is the URI Path, minus any querystring parameters.



"Push-Asset-Key" is also a required PUSH_PROMISE header, which is likely part of the confusion. Being a PUSH_PROMISE is essentially the server delivering a request on its behalf, this header field informs the client that this resource should be tracked as a "Push-Asset" (aka push-enabled). The key itself is what uniquely identifies the resource, and will typically be the URI Path of the resource, minus querystring parameters, but in MD5 form. The client will only ever provide client cache state of resources that have responded with this header field, as they are "push-enabled". This gives the server control of what state it should or should not track for the purpose of Server Push resources.



"Push-Asset-Match" is an optional response header. This effectively allows the server to inform the client that a given resource is only used within specific "buckets" of matching URI's. This is especially useful for large or complex domains, such as CDN's, or other multi-app-per-domain scenarios.





I'll continue to collect feedback, and especially suggestions, and update the next draft accordingly. Thanks again for the interest.







-aaron

________________________________
From: Martin Thomson <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, July 12, 2016 5:52:49 PM
To: HTTP Working Group; Aaron L. Silvas
Subject: draft-asilvas-http-push-assets-00 comments

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.