Bob, thank you for your thorough review.
I think we have addressed or Lucas has responded to most of the points, but I've been notified that the point below has been left to me.
2021年12月21日(火) 21:17 Bob Briscoe <ietf@xxxxxxxxxxxxxx>:
T#5c) Nothing said about caching and priority
The paragraph about caching and priority just ends having talked a bit about
caching but not about priority. It left me none the wiser about what a cache
ought to store about priority with the response. §13.8 talks about fairness
between multiple live connections in the presence of coalescing. But doesn't
the discussion of caching and priority here need to talk about what
must/should/may be stored about priority in a cache for later connections. Even
if it's implementation dependent, wouldn't it be worth a brief discussion (as
in the 2 paras below).
The priority of a response is the outcome of an interaction between the
client's original (e2e) priority combined with the server's logic about the
resource. If only the priority outcome is stored, then when another request
arrives at the cache from a different client, there will be no record of the
original client's priority. So the cache will not know what client priority
led to the priority stored with the response. And it will not know whether the
current client priority is the same or different.
On the other hand, if the cache stores the original client priority with the
response priority, then should it refer a request with a different (e2e) client
priority to the server, then store the new pair of priorities with the original
cached response? And I guess it could serve the request in parallel, rather
than waiting for the server to tell it whether to serve the request urgently
(!). This would probably scale reasonably well, given the likely small number
of different client priorities. But who knows how it would scale if the
parameter space is extended in future.
Answer supplied by Kazuho - As discussed in the last paragraph of section 5, CACHING defines if and how requests with different header field values can be mapped to one response. If the capabilities provided by CACHING (i.e. Vary) is too limited, then we should fix that as an extension to CACHING (as have been previously proposed as draft-ietf-httpbis-key). In practice, re Extensible Priorities, IMO, there aren't many sensible combinations of urgency and incremental. Therefore, backend servers that want to tune priority based on the value that the client sends can simply send Vary: priority and call it a day.
[BB] I think my point has been missed. I'll try an example:
Client A requests
priority u=4
Server responds
priority u=2,
which gets cached.
Client B requests same object
priority u=4.
Client C requests same object
priority u=0
If requests B & C were forwarded to the origin, it would respond with
priority u=2 # for B
priority u=0 # for C
However, even though the cached object has the same priority header that the origin server would give to Client B's request, it's different to that cached. And the cache cannot tell that B's request would match, but C's wouldn't.
Vary doesn't help here, does it? At least not without storing the client request priority as well as the server response.
[KO] Vary does exactly that.
Quoting from draft-ietf-httpbis-cache-19 section 4.1: When a cache receives a request that can be satisfied by a stored response and that stored response contains a Vary header field (Section 12.5.5 of [HTTP]), the cache MUST NOT use that stored response without revalidation unless all the presented request header fields nominated by that Vary field value match those fields in the original request (i.e., the request that caused the cached response to be stored). https://httpwg.org/http-core/draft-ietf-httpbis-cache-latest.html#rfc.section.4.1.p.1
Kazuho Oku
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
