RE: Cache-Control Interpetation

www-talk@w3.org,

I thought we were discussing it, and supposing Cache-Control had parameters,
BUT Cache-Control does NOT have any parameters. I lost a lot of e-mails
(also regarding this cache-control issue; after 19-apr-00) after doing
something really stupid before reinstalling my computer (removing my e-mail
messages accidentilly).
However, someone introduced the Cache-Control header-value:

	no-cache, community="UCI", max-age=30

This can be really simply interpeted (and possibly correct):
* no-cache: The response is not cacheable (or may not be retreived from
cache)
* community="UCI": AND cachable for the UCI community...

* max-age=30: Another aspect, the response it's maximum age may be 30
seconds.

---

Look at this one from RFC2616 (latest HTTP/1.1 spec):
	private, community="UCI"

* private: The response may be cached by private caches
* community="UCI": The UCI community may cache the response (including UCI's
shared caches!).

---

Now a nice one:
	no-cache, private, community="UCI", max-age=60, s-maxage=45

Interpetation:
* no-cache: The response is not cachable (or may not be retreived from
cache)
* private: Only private caches may cache it, this conflicts with no-cache,
so we prefer the most strict one: no-cache (hope you agree)
* community="UCI": AND cachable for the UCI community.

* max-age: maximum age is 60 seconds.
* s-maxage: however, maximum age for shared caches is 45 seconds.

Here it goes wrong! no-cache and private will conflict, and never forget:
there are no parameters. But it may be of good use if future HTTP/1.1 caches
(what will not be likely) or HTTP/1.2 caches should support these.

Another, but wrong interpetation whould be:
* no-cache: The response is not cachable
* private: Conflicts with "no-cache", so whats after it?
	* community="UCI": So suggest it may be cache by UCI's private caches.
* max-age=60: maximum age is 60 seconds.
* s-maxage=45: maximum age for shared caches is 45 seconds, but this one is
never used.

This interpetation should be considered wrong, because it suggest that
parameters are used, but they are NOT.

---

Suppose the new form whould be (BNF syntax) for the Cache-Control header:

Cache-Control = "Cache-Control" ":" 1#( Cache-Directive
                                    [ *( ";" Cache-Parameter ) ] )
Cache-Parameter = Cache-Directive

New cache-control directive:
Community = "Community" "=" Community-Name
Community-Name = qouted-string
The directive will indicate the directive will only apply for a specific
community. If there are no parameters with this directive, then it's
publically cachable for that community.

Now we whould require (for HTTP/1.1 backward compatibilty) that the first
cache-directive to have NO parameters and must have the most important
directive to be used by all HTTP/1.1 caches, if they don't understand the
rest of the syntax. This is to ensure backward compatibility.
The order of the cache-directives and parameters is not restricted and may
not lead to other interpetations. Parameters will always override global
directives (hope I made my point).
One restriction that must be clear is that "no-cache", "no-store",
"private", "public" may not appear together in one directive and it's
parameters, or appear globally without parameters.
In this cache it whould be possible to make a good cache-control directive:

no-cache, private; community="UCI", max-age=60, community="2nd";
community="3rd"; s-maxage=30; max-age=30

Looks complex, but it is not:
* no-cache: Reponse not cachable
* private; community="UCI" (older HTTP/1.1 caches would ignore this one)
	- private: only applies to private caches
	- community="UCI": of the UCI community.
* max-age=60: maximum age is 60 seconds (the global one)
* community="2nd"; community=3rd"; s-maxage=30; max-age=30 (older HTTP/1.1
will ignore)
	- community="2nd": applies to the 2nd community
	- community="3rd": AND to the 3rd community.
	- s-maxage=30: maximum age for shared caches is 30 seconds
	- max-age=30: maximum age for all other caches is 30 seconds.

Conclusion:
The response is not cachable, except for:
* "UCI" community private caches, if the maximum age is 60 seconds (global
directive) AND
* "2nd" and "3rd" community, if the maximum age is 30 seconds, and for
shared caches 30 seconds.

And older HTTP/1.1 caches will find:
	no-cache, max-age=60.
Now hope they interpet this as uncachable.


I think this syntax is compabilible with the existing HTTP/1.1 caches. Maybe
it needs a revision, but I don't suppose it does. This is most likely the
best way for caches to indicate explicitly what they want. Maybe a
consideration for the next HTTP/1.1 RFC or extention to HTTP/1.1.



Joris.



-----Original Message-----
From: Koen Holtman [mailto:koen@win.tue.nl]
Sent: maandag 1 mei 2000 22:49
To: Joris Dobbelsteen
Cc: www-talk@w3.org
Subject: Re: Cache-Control Interpetation


>If a Cache-Control header is received with e.g.
>	no-store, community="UCI", max-age=30
>from your sample (another discussion).
>
>Can a client or proxy server only use the first word: "no-store". On the
>proxy I'm writing, the goal is to only look at the first word: "no-store",
>simply assuming the rest is meant as a parameter from this keyword.

You cannot make the assumption that the rest is a parameter.  HTTP/1.1
makes no guarantee that the 'most important' cache-control keyword
appears first.  You really have to look at all the keywords.  If you
only look at the first word you will fail to make the correct caching
decision in some cases.

>Thereby isn't it a better way to send something like this?????
>	no-store, community="UCI; max-age=30
>
>this way you can interpet the cache (for community-aware proxies/clients)
>should use no-store if there community is "UCI", otherwise they should use
>max-age=30????

There is some logic in your proposed syntax, but the HTTP/1.1 spec is
finished so it is probably too late to make syntax extensions like
this.

>
>
>
>Another question, where can I find information about community-aware
>caching? (RFC #?)

RFC2616 has a notion of a shared vs. private cache.  I'm not aware of
any RFC's that go deeper than that into the subject.  If you are
looking for community-aware caching software or cache optimisations, I
think conference proceedings are a better bet than RFCs.

>
>
>
>Joris Dobbelsteen
>

Koen.

Received on Thursday, 4 May 2000 10:03:07 UTC