Extensibility

[mnot]

... to express things like evolved digest formats, inclusion of stale cache entries, etc. as discussed in #167.

[mnot]

See changes above. I don't think it's necessary to establish a registry at this point; a future spec can do that if necessary, or they can just update this one.

[kazuho]

I am not firmly against having Digest-Length field, but can't we just send multiple CACHE_DIGEST frames in case we want to send digests in other formats or stale entries?

Consider the case of using another encoding. In the case, it is likely that we would need to have attributes other than N and P, and that means that the structure prior to Digest-Length would become different. In other words, there might be no merit in having the Digest-Length field (at this position) for the case.

Also in the case of sending stale digest only (a browser may not have any fresh resources cached), there's no need to send a Digest-Value of fresh entries.

To summarize, number of octets saved for having the Digest-Length field is as follows.

1. -3 in case only fresh digest is sent
2. 6 in case both fresh and stale digests are sent
3. 3 in case only stale digest is sent
4. -3 in case the digest is sent using another encoding

As can be seen, it is unclear if we gain or loose. Considering the fact that digests would be more than just a few octets, I think we can live out without trying to make this small optimization.

PS. If we are to use separate CACHE_DIGEST frames for sending every kind of digest (in other encoding or covering stale cache entries), I think we should use the flags fleld of the frame header to distinguish them.

[mnot]

I'm absolutely fine with not having Digest-Length; I'd just thought that the conclusion of the discussion on the pull request was that the frame type needed to be extensible, and that seemed like the simplest way to allow it.

If we are to use separate CACHE_DIGEST frames for sending every kind of digest (in other encoding or covering stale cache entries), I think we should use the flags fleld of the frame header to distinguish them.

In #176 you prefer putting the partial/complete flag in the payload; I tend to think that we should have one place for flags.

We could just go ahead and define the following two header flags:

1. reset - if 1, indicates that all cache state should be cleared before processing the frame (i.e., a client that always sends complete digests will send reset each time).
2. fresh/stale - 0 indicates stale entries, 1 indicates fresh.

... leaving the rest for future definition.

WRT changing the digest encoding/format - I tend to think that we might as well define a new frame type if we want to do that (that's very much in the spirit of H2 extensibility; frame types are reasonably cheap).

[kazuho]

I'm absolutely fine with not having Digest-Length; I'd just thought that the conclusion of the discussion on the pull request was that the frame type needed to be extensible, and that seemed like the simplest way to allow it.

👍 Thank you for the clarification.

If we are to use separate CACHE_DIGEST frames for sending every kind of digest (in other encoding or covering stale cache entries), I think we should use the flags fleld of the frame header to distinguish them.
In #176 you prefer putting the partial/complete flag in the payload; I tend to think that we should have one place for flags.

Sounds sensible. No objections.

We could just go ahead and define the following two header flags:

1. reset - if 1, indicates that all cache state should be cleared before processing the frame (i.e., a client that always sends complete digests will send reset each time).
2. fresh/stale - 0 indicates stale entries, 1 indicates fresh.

... leaving the rest for future definition.

+1 to adding reset.

For stale digest, I believe we need to figure out how to push a cache validator (and my preference goes to HEAD). Do you have any plans to write an I-D for that, or shall we?

And as said, I have no objections on defining partial as the third flag.

WRT changing the digest encoding/format - I tend to think that we might as well define a new frame type if we want to do that (that's very much in the spirit of H2 extensibility; frame types are reasonably cheap).

Yeah! Thank you for standardizing H2.

[mnot]

reset has the same effect as partial -- it indicates when the frame's contents should be added to the set of current digests, or when it should remove them all and start fresh. Does that make sense, or did you have another semantic in mind?

[kazuho]

@mnot Thank you for the clarification. It does make sense and I agree that we should have it.

[kazuho]

Thank you for the updates!

Note that Last-Modified is not included (yet); do we need it, or can we get away with just ETag?

I have no objections to omitting last-modified (esp. considering the fact that users can work-around the issue by coverting last-modified to etag in their reverse proxy configuration).

Also, server-side behaviour is not defined; I think we need a separate "how to do server push" document for that.

Sounds like a sensible thing to do.

Regarding the flags, could we define VALIDATORS and STALE defined as a single flag?

I am not sure what we can gain by having the two defined separately - I believe they would always be used together (both set to 1, or both set to zero).

[mnot]

It would allow you to push the validators for fresh responses, in case someone wanted to invalidate something that's fresh. Not a use case now, but it might be interesting in the future.

[kazuho]

It would allow you to push the validators for fresh responses, in case someone wanted to invalidate something that's fresh. Not a use case now, but it might be interesting in the future.

Thank you for the clarification. Understood. No objection to having two flags.