- From: Koen Holtman <koen@win.tue.nl>
- Date: Sun, 14 Apr 1996 19:07:20 +0200 (MET DST)
- To: http-caching@pa.dec.com, jg@w3.org
- Cc: koen@win.tue.nl (Koen Holtman)
All right, it is compromise time! I have argued before that the requirement Varying resources (even those that are transparently negotiated) MUST send responses which include variant-IDs. which is present in both Jeff's If-Valid/If-Invalid/Cval text and Roy's competing If-EID/Unless-EID/EID text must be dropped, because this requirement means unnecessary trouble for transparent content negotiation. My arguments have failed to convince both Jeff and Roy. Therefore, I now propose a compromise which, in my view, - adds an unnecessary requirement to 1.1 - will mean more bytes over the wire - will add unnecessary complexity to caching proxies - will certainly make transparent negotiation slightly more complicated than the mechanism in draft-holtman and, worse - MIGHT make transparent negotiation horrendously more complicated than the mechanism in draft-holtman without me noticing it now, so that we have can't build a nice transparent negotiation mechanism on top of 1.1. I propose this compromise because we will need a compromise in order to get finished with 1.1 in time. Adapting text from revision 31 of Jim's 1.1 draft, this is what I propose: 10.47 CVal The CVal header is used to transmit opaque cache validators in HTTP/1.1 responses. CVal = "CVal" ":" cval-info cval-info = opaque-validator [ ";" variant-id ] | variant-id = vary-part | | alternates-part | | ( vary-part "/" alternates-part ) | | vary-part = token | alternates-part= quoted-string | | [##I want this extra structure in variant-ids because, in order for | transparent negotiation to be as efficient as it can be, _proxys_ | will sometimes have to assemble variant-IDs from various components | on behalf of the origin server. I can explain why proxies would | need to do this examples, but will not do so here.##] | A variant-id MUST be present in a Cval header in all responses from | varying resources [## Note that all varying resources include a Vary | header, an Alternates header, or both##]. A vary-part must be present | if a Vary header is present in the response. An alternates-part must be | present if an Alternates header is present in the response. | [##The alternates-part basically replicates the information that is | also in the Content-Location header of an opaquely negotiated | response##] Examples: CVal: "xyzzy" CVal: "xyzzy"/W CVal: "xyzzy"; 3 | CVal: "xyzzy"/W; ".en.html" | CVal: "xyzzy"/W; 4/".en.html" | [##Note that this last example is a strange beast: we are dealing | here with a resource that is partially negotiated opaquely, and | partially negotiated transparently. I don't expect such resources to | be common. However, the need to allow these resources to exist is | the main reason why I need structure in the variant-id.##] Note that the variant-id is not part of the opaque validator. The CVal field is used to transmit a variant-id simply as a matter of compact representation of responses. 10.48 SLUSHY: If-Invalid [....] If-Invalid = "If-Invalid" ":" if-invalid-rhs if-invalid-rhs = opaque-validator | variant-set variant-set = 1#variant-set-item variant-set-item = opaque-validator ";" variant-id The correct form (opaque-validator or variant-set) depends on whether or not the request is being made to a varying resource. If the server has returned a variant-id in the CVal header of a prior response, a conditional GET on this resource MUST use the variant-set form, and SHOULD include the variant-set-items for all the cache entries (fresh or not) associated with the resource. Note: although the protocol does not prohibit the use of the Range header with a multi-item variant-set, it is not clear that this will always yield a useful result. Examples of single-entity form: If-Invalid: "xyzzy" If-Invalid: "xyzzy"/W Examples of multiple-entity form: If-Invalid: "xyzzy";4 If-Invalid: "xyzzy";3, "r2d2xxxx";5, "c3piozzzz";7 | If-Invalid: "blebber"/W;".en.html", "gonkxx"/W;".nl.html" | If-Invalid: "blebber"/W;zip/".en.html", | "gonkxx"/W;none/".nl.html" If the request would, without the If-Invalid header, result in anything other than a 2xx status, then the If-Invalid header is ignored. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. 13.20 Cache replacement for varying resources | [##Note that the text below does not mention the Content-Location | header anymore##] If a new 200 (OK) response is received from a non-varying resource while an old 200 (OK) response is cached, caches can delete this old response from cache memory and insert the new response. For 200 (OK) responses from varying resources (Section 10.v), cache replacement is more complex. HTTP/1.1 allows the authors of varying resources to guide cache | replacement by the inclusion variant IDs in the responses of these | resources. If a cache has stored in memory a 200 (OK) response with a certain | variant ID, and receives, from the same resource, a new 200 (OK) | response which has the same variant ID, this should be interpreted as a signal from the resource author that the old response can be deleted from cache memory and replaced by the new response. | The variant ID mechanism cannot cause deletion from cache memory of | old responses with variant IDs that will no longer be used. It is expected that the normal `least recently used' replacement heuristics employed by caches will eventually cause such old responses to be deleted. | All 200 (OK) responses from varying resources should include variant | IDs. Koen.
Received on Sunday, 14 April 1996 17:43:53 UTC