An HTTP response can nominate a set of headers pertaining to the initiating request, using the Vary header, to be matched against by the incoming request before being served by caches. This makes it possible to have multiple responses per URI (e.g. one for Accept-Encoding: gzip and another for Accept-Encoding: brotli for a Vary: Accept-Encoding). The prospect of implementing this seems nice due to the hypothetical increase in hit rates (the current behavior is to only keep the latest response). However, this makes it tricky to handle some cases like entry locking (lock edits on the entry scope or response scope?) & response updates (knowing which response to update).
A major part of this is re-specifying the Store API to act more like a Map<String, List<Entry>>. Let's prioritize #50 to have a better idea of the implementation concerns of such a change.
An HTTP response can nominate a set of headers pertaining to the initiating request, using the Vary header, to be matched against by the incoming request before being served by caches. This makes it possible to have multiple responses per URI (e.g. one for
Accept-Encoding: gzipand another forAccept-Encoding: brotlifor aVary: Accept-Encoding). The prospect of implementing this seems nice due to the hypothetical increase in hit rates (the current behavior is to only keep the latest response). However, this makes it tricky to handle some cases like entry locking (lock edits on the entry scope or response scope?) & response updates (knowing which response to update).A major part of this is re-specifying the Store API to act more like a
Map<String, List<Entry>>. Let's prioritize #50 to have a better idea of the implementation concerns of such a change.