Re: Suggestion: Add Cache-Control extensibility to Vary header

Henrik Frystyk Nielsen:
>
>At 07:21 PM 3/16/97 +0100, Koen Holtman wrote:
>
>>In stead of 
>>
>> Vary: Protocol, "http://some.org/a-required-extension"
>>
>>you can just as well use
>>
>> Vary: Protocol
>> Cache-control: vary-protocol="http://some.org/a-required-extension"
>>
>>or something, so there is no need to revise the Vary syntax: just use the
>>extensible cache-control syntax to convey your extra directive.
>
>This is not exactly what I am trying to achieve. It is not a question of
>describing which parts (headers, body, or complete message) of a response
>that are cacheble or not

I know the above is not a case of cache-control saying something about the
cachability of some part of the response.  But you are still allowed to use
the cache-control extensibility mechanism to get the extension you want.  If
it controls caches, it can be put in cache-control.  

You can also define a completely new header if you want.  My point is that
there is no need to incompatibily extend the unextendable Vary header.

[...]
>>You can also use the following hack, which will get you what you want even
>>under the current HTTP/1.1 spec.  If you have multiple protocol headers but
>>only want caches to vary on one, include an extra header like
>>
>>Proto-Vary: {http://some.org/a-required-extension {str "req"}}
>>
>>in the response, and send "Vary: proto-vary" in stead of "Vary: protocol".
         ^^^^^^^^
                Oops! I should have written request here

>>Strange, but fun.  Of course, you would usually want to have a shorter
>>encoding in the above proto-vary header.
>
>Throwing in random new headers is exactly what PEP tries to avoid

Yes, you have a point.  The above is a hack: if this functionality would be
needed often, you are better off defining clean new mechanism.

>Henrik

Koen.

Received on Wednesday, 19 March 1997 02:03:16 UTC