W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2002

Re: Label header vs PROPFIND depth 1

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Thu, 25 Apr 2002 10:36:06 +0200
Cc: "'Deltav WG'" <ietf-dav-versioning@w3.org>
To: <tim@ellison.name>
Message-Id: <7C59F764-5827-11D6-9959-00039384827E@greenbytes.de>

Am Mittwoch den, 24. April 2002, um 17:50, schrieb Tim Ellison:

> Stefan Eissing wrote:
>> The result of a GET has to be cacheable by HTTP proxies.
> I see nothing to prevent the response from a GET including a 
> 'Cache-Control:
> no-cache' header.  Why do you say that?

Then 3253 must require that DeltaV servers send no-cache on resonse
to *all* GETs on VCRs. Otherwise it breaks proxies.

>> For the LABEL header to be compliant with GET, it has to
>> select a variant (as variant in rfc2616) of the resource
> I disagree that it has to select a variant (or at least I haven't 
> been shown
> why yet).

I think we do not share a common definition of "variant" and that
is causing all the confusion.

In my thinking a variant is what is returned by GET on a URI.
A lot of HTTP resources just have one variant at one point in
time. The cacheability of that is mainly influences by the Expires
HTTP header.
Some resources however have more than one variant at one point
in time. For example "Accept-Language" might influence which
variant is returned by GET. A server then should indicate in
the Vary response header which *request* header influences
the response. Caches will then only return cached results when
those request headers match.

Of course, DeltaV could disable all caching by requiring servers
to return "Cache-Control: no-cache" on all GET responses for VCRs.

I personally think this should be avoided.


>>  and declare so in the Vary header.
> The Vary: header doesn't state the result is a variant, or otherwise.
>> I think there is no way around it without breaking GET and I hear
>> that Roy Fielding has got a big knife and is after the SOAP guys for
>> related matters...
> How does it break GET?  (This discussion is drifting all over the map!)
>> I think LABEL has to be rethought.
> Clearly it has to be clarified.  We had a number of working group 
> review
> periods, and all the authors signed it off in it's current form; 
> so I hope
> it isn't too far away from sanity.
> Regards,
> Tim
Received on Thursday, 25 April 2002 04:37:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC