Subject: Re: [httpwg/http-extensions] Avoid sending the digest when not used (#410)

From: HTTP issue updates <[email-masked]>
Date: Thu, 01 Feb 2018 09:58:48 -0800

Yes, but it's not the mechanics of how to send digests for multiple domains that I'm questioning.  It's determining *which* domains to send.  I see the thrust of this issue as being that the spec currently provides mechanics, but a lack of guidance to clients on how to use it.

The domains are likely coalesced because there are subresources that span them.  So while the client might know it wants to make a request of www.example.com, the server knows it wants to push resources for img.example.com and dynamic.example.com as well, and needs to see those digests.

For HTTP/QUIC and variable-length settings, I would say the server sends a setting that's the list of domains it would like to see the digests for.  That's less feasible in HTTP/2's 32 bits.  (You could overload ORIGIN, but assuming that the desired set is less than all the origins the server supports....)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/410#issuecomment-362349927

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 02 Feb 2018 03:49:59 +0000 (UTC)

Or an extension flag on ORIGIN that indicates what origins the server wants CACHE_DIGEST for. Although arguably, simply getting an ORIGIN covering a given origin indicates interest in CD for it. If a server adds an origin to a connection, that's a pretty strong signal it expects to have requests for it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/410#issuecomment-362478383

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 02 Feb 2018 05:38:04 +0000 (UTC)

I think that the draft already defines a way for a server to notify the client if it wants to see a digest (see [ACCEPT_CACHE_DIGEST parameter](http://httpwg.org/http-extensions/draft-ietf-httpbis-cache-digest.html#the-acceptcachedigest-settings-parameter)). However, the information is currently tied to the connection instead of the origin.

That said, one way of addressing the issue would be to add a way to define per-origin settings to the ORIGIN frame. Considering the fact that the use of the SETTINGS parameters is the suggested way for negotiating features, it would be natural to provide the opportunity to use them at a per-origin basis.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/410#issuecomment-362491714

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 12 Feb 2018 00:46:56 +0000 (UTC)

A client->server "I'm going to send a CD, you might not want to push until you see it" setting sounds reasonable to me. I would imagine that clients that support CD will always send it; servers that think they know better can ignore it, of course.

ACCEPT_CACHE_DIGEST seems like it's optimised for the case that the browser doesn't want to send CD until it knows the server wants it, and it's OK if it doesn't show up in the first RT or two of the connection -- i.e., the client sends it sometime after the first request, and everyone is willing to wear a bit of inefficiency in the first few pushes, because we assume that there will be further interactions on the connection that can benefit from CD.

I think I agree that doesn't work so well for 3rd party content. 

However, making settings persistent beyond  the scope of a connection is something we've shied away from in the past; it's effectively defining a new kind of cache. Also, from a developer experience perspective, emitting new SETTINGS is not easy from some servers (never mind load balancers, CDNs, etc).

If @mikewest's [Origin Policy](https://wicg.github.io/origin-policy/) had any life in it, that might be appropriate here. Alternatively, we could define a well-known resource for this sort of origin-wide HTTP configuration along the lines of [Site-Wide HTTP Headers](https://mnot.github.io/I-D/site-wide-headers/). 

That would make the interaction something like:

~~~
c                                    s
+   SETTING WAIT_FOR_MY_DIGEST       +
|   SETTING I_WANT_HTTPSTUFF         |
|         GET /whatever              |
| +--------------------------------> |
|                                    |
|    PUSH /.well-known/httpstuff     |
| <--------------------------------+ |
|                                    |
|        200 OK /whatever            |
| <--------------------------------+ |
|                                    |
|        CACHE_DIGEST                |
| +--------------------------------> |
|                                    |
|    PUSH some other stuff           |
| <--------------------------------+ |
|                                    |
|                                    |

~~~

WDYT? Of course, we could also define a response header to do this, or a couple of other things.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/410#issuecomment-364806895