Re: Submitted new I-D: Cache Digests for HTTP/2

2016-01-15 15:33 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
> On 15 January 2016 at 17:23, Kazuho Oku <kazuhooku@gmail.com> wrote:
>> A server should merge the values of the cache-digest headers to
>> construct the client's cache digest.
>
>
> I don't think that this would be a good idea.  I would rather try to
> use the "scope" parameter to narrow things down, to omit the header
> field if there aren't changes, or rely on the server performing some
> sort of "magic" tracking based on what it has sent.

I doubt if the approach will work well with SW-based implement ion of
cache-digests (which is one of the reasons why we want it to be
defined as a header).

My understanding is that Fetch API does not expose to the caller if a
connection is being reused or if a new connection is established.
Therefore, unless it includes entire cache digest in every HTTP
request, there is a chance that the digest value will not be available
to the server (in case a new connection was established).

Considering the fact that such APIs (that are incapable of expressing
states shared between the requests) exist, I think the semantics
should be defined in a way that every HTTP request can be complete by
itself if we are going to send cache digest as a header.

Please correct me if I misunderstand the Fetch API.  I am not familiar with it.

> The upshot of using a header field is that this really means that this
> isn't hop-by-hop information.  Like Ilya said, I doubt that's a huge
> problem.  Nothing stopping an intermediary from consuming, modifying,
> or inserting the value though.

Thank you for the clarification.

I had thought that it is, considering the fact that intermediaries may
have cache associated to them (and thereby want to change the value of
the header).  However considering the fact that If-Modified-Since
header is not defined as a hop-by-hop header, now it seems to me that
you are correct.

-- 
Kazuho Oku

Received on Friday, 15 January 2016 07:01:55 UTC