Re: Possible new issue: Things with and without identity?

>> A "WebDAV resource" is just an HTTP resource.  Any resource that allows
>> PUT cannot vary depending on the headers of a GET request, since
>> any such variance would be eliminated by the PUT.  However, other
>
> That would basically mean that for every URI to which I can apply PUT,
> there's only one representation a subsequent GET will deliver, so it 
> doesn't
> vary.

Yes.

>  It's certainly possible to use PUT this way, but I'm wondering where
> the HTTP spec makes this a requirement?

The method PUT.

> Looking at section 9.6, it seems
> also plausible to consider GET and PUT to be symmetric. So I'd be allowed 
> to
> PUT to different representations of a resource with, let's say, varying
> "content-language" headers. If you say that this is illegal, I'd like to
> understand where RFC2616 forbids that.

How is the server supposed to know that it is a variant instead of a
replacement for the current representation?  The answer is that they are
different URLs.

> Is there possibly another RFC that would say more about authoring HTTP
> resources that can vary?

The RFC that contains the definition of the source link, wherever that
might be.

>> resources that are derived from that resource may also be impacted by
>> that PUT, and those other resources may vary depending on headers.
>> That is the nature of content negotiation in HTTP -- the negotiable
>> URI is never the same as the source URI.
>
> Q: you're using the term "source URI" as if it was formally defined
> somewhere... If I understand you correctly, the source URI upon a GET that
> varies would be the URI returned in the "Content-Location" header, right?
>  As
> far as I understand section 14.14, a server MAY report this URI, but it
> doesn't have to. So, is your point that for an authorable resource, there
> should *always* be a source URI for each individual entity that can be
> modified?

There is always at least one source URI for every resource, period.
It is an established metadata relationship that should be painfully
obvious -- every externally visible resource is composed of other
resources, only some of which may be externally visible and accessible
to the client.  An HTTP server composes representations of one resource
by selecting and composing from a set of internally defined resources.
A file URL identifies a resource too.

Whether or not the URL is advertised in Content-Location is not
important to this process -- that is just extra bookmark information.

....Roy

Received on Friday, 13 September 2002 05:37:48 UTC