- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Thu, 12 Sep 2002 20:30:51 +0200
- To: "Roy T. Fielding" <fielding@apache.org>
- Cc: <uri@w3.org>
> From: uri-request@w3.org [mailto:uri-request@w3.org]On Behalf Of Roy T. > Fielding > Sent: Tuesday, September 10, 2002 6:49 PM > To: Julian Reschke > Cc: uri@w3.org > Subject: Re: Possible new issue: Things with and without identity? > > .. > > >> WebDAV talks about it that way because, for the purpose of authoring, > >> it doesn't matter whether there is a distinction between the resource > >> and the current representation of that resource -- they become > >> effectively > >> the same thing because WebDAV actions exist at an instant in time and > >> only work on resources that are directly authorable (one-to-one > >> relationship between representation and resource). > > > > That's news to me. Are you saying that WebDAV resources may not vary > > depending on the headers in a GET request? > > 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. It's certainly possible to use PUT this way, but I'm wondering where the HTTP spec makes this a requirement? 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. Is there possibly another RFC that would say more about authoring HTTP resources that can vary? > 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? Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 12 September 2002 14:31:24 UTC