W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

Re: Managing multiple authorities, resources and representations

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Sun, 13 Jun 2010 23:21:33 +0200
To: nathan@webr3.org
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <1276464093.6334.25.camel@henriknordstrom.net>
tor 2010-06-10 klockan 13:03 +0100 skrev Nathan:

> 1: I can't find any definition of the term 'general URI', can you clarify?

Any normal URI supporting PUT.

> 2: How does an origin-server inform a client in a Response that several 
> other URIs have been defined, and indeed what URIs they are?

It doesn't.

The response body SHOULD contain relevant information to the human user.

> 3: Does the Working Group have any guidance on whether:
>   (a) the other URIs must or should be under the same authority as
>       specified in the client Request (ie the same domain name)
>   (b) the other URIs must or should use the same scheme

Up to the implementer. It's not the protocols job to define or restrict
effects on other URIs than the requested URI.

> 4: Is some conflation introduced by swapping terminology / context from 
> 'creating resources' to 'defining URIs', what's the difference?

Not sure I understand the question. But I guess none. The protocol
operates at URI level, not going into details of how a server maps URIs
to resources.

To aid complex URI mappings Content-Location etc can hint about the
mapping, by prioviding a unique URI for a specific representation.

>  From HTTPBis p2-semantics-09 section-7.5 | POST:
>    'If a resource has been created on the origin server, the response
>     SHOULD be 201 (Created) and contain an entity which describes the
>     status of the request and refers to the new resource, and a Location
>     header (see Section 9.4).'
> 
> 5: No mention of creating multiple resources / defining multiple URIs, 
> thus is this allowed or not (must, must not, should, should not etc)

MAY.

Location indicates the primary.

Response body MAY describe any secondary URIs created or modified by the
request.

> 6: If the answer to question 5 above is in favour of allowing several 
> resources to be created (or URIs to be defined) then request 
> clarification of questions 2 and 3 in relation to POST as well.

See answers above. Applies for POST as well, in fact pretty much any
method..

>  From HTTPBis p2-semantics-09 section-6.1 | Identifying the Resource 
> Associated with a Representation:
>     '3.  If the response has a Content-Location header, and that URI is
>         the same as the request-URI [[TODO-missref-requri: (see [ref])]],
>         the response is a representation of the resource at the request-
>         URI.'
> 
> 7: Is the mapping between resource and representation always 1-1 at a 
> given instant, or as indicated by content negotiation might the mapping 
> be 1-Many?

Complex.

But specs focus on an URI level, not caring much if the same resource
may be accessible via other URIs.

> 8: With server side content negotiation implemented over the Accept 
> header, and where the origin-server does not define a per representation 
> unique URI for direct access to each representation that is returned, 
> then are all representations considered to be representations of the 
> resource at the identified request URI?

Yes, and also the same if Content-Location is given. Content-Location do
not change the meaning of the response for the request-URI, it just
declares another URI where this representation may be accessed without
relying on negotiation.

> 9: Can one use PUT on a request URI which responds with multiple 
> representations (for instance different serializations of the same data) 
> where the Content-Location is always the same as the request URI?

Yes, if supported by the server. But this then replaces ALL
representations effectively disabling content negotiation.

>  From HTTPBis p2-semantics-09 section-7.7 | DELETE:
>    'The DELETE method requests that the origin server delete the
>     resource identified by the request-target.'
> 
> 10: Multiple possibly obvious-by-now questions that all fall under two 
> points:
>   (a) Is an origin-server free to DELETE the other URIs that were defined
>       when the resource identified by the request-target was created?

Yes. But not required to do so.

>   (b) depending on (a) - If multiple URIs are defined on PUT, how does
>       one DELETE those URIs if they are unknown to the client/creator?

Implementation specific. Either the server deletes them all, or the
client need to discover the created URIs somehow and DELETE them
individually if supported. MAY well be the case that not all URIs
created can be DELETEd. An example given in earlier discussions is a
version controlled store where every resource have at least two URIs,
the normal URI and a version specific URI. DELETE can then only delete
the normal URI which creates a new "deleted" version of that URI, but
the version specific URIs can not be deleted or modified in any manner.

>   (c) given questions 7-9 and assuming that the mapping between resource
>       and representation is 1-Many, then [ can | should | must ] all
>       representations be DELETEd when the identified resource is?

Implementation specific.

> I think that covers everything I need, (apologies if needed!)

No apologies needed. Very valid questions.

Regards
Henrik
Received on Sunday, 13 June 2010 21:22:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:20 GMT