Variant-ID proposal

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