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

Hello Aaron,

I'm also very interested on understanding your proposal better. I have read
your draft and then have followed the questions asked on this list  and now
your clarifications. However, neither your examples in the draft nor your
latest email have helped me. Could you please repeat your examples with
full request/response headers and with annotations about which requests are
part of a PUSH_PROMISE?

You mention that "browser and server adhere to a strict dependency state
contract".... can you describe this contract?  Compared with the situation
today, what are the major differences?

Thanks in advance,

./Alcides.



On Wed, Jul 13, 2016 at 6:24 PM, Aaron L. Silvas <asilvas@godaddy.com>
wrote:

> 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 <martin.thomson@gmail.com>
> *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.
>



-- 
Alcides Viamontes
www.shimmercat.com