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

> From: uri-request@w3.org [mailto:uri-request@w3.org]On Behalf Of Roy T.
> Fielding
> Sent: Friday, September 13, 2002 11:30 AM
> To: Julian Reschke
> Cc: uri@w3.org
> Subject: 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.

Could you be a bit more specific?

RFC2616 says:

"The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already existing
resource, the enclosed entity SHOULD be considered as a modified version of
the one residing on the origin server. If the Request-URI does not point to
an existing resource, and that URI is capable of being defined as a new
resource by the requesting user agent, the origin server can create the
resource with that URI. If a new resource is created, the origin server MUST
inform the user agent via the 201 (Created) response. If an existing
resource is modified, either the 200 (OK) or 204 (No Content) response codes
SHOULD be sent to indicate successful completion of the request. If the
resource could not be created or modified with the Request-URI, an
appropriate error response SHOULD be given that reflects the nature of the
problem. The recipient of the entity MUST NOT ignore any Content-* (e.g.
Content-Range) headers that it does not understand or implement and MUST
return a 501 (Not Implemented) response in such cases."

> > 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.

The answer is: it could. This may fail with "arbitrary" variations, but it
certainly possible for things like "content-language".

> ..
>
> >> 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.

Well. What *is* a source URI?  I was looking for a definition.

> 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

OK. I have a HTTP resource server by moddav, which doesn't vary and which is
PUTtable. Of which other resources is it composed?

> 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.
> ...

Regards, Julian



--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 13 September 2002 06:06:54 UTC