Subject: Managing multiple authorities, resources and representations

From: Nathan <[email-masked]>
Date: Thu, 10 Jun 2010 13:03:05 +0100

Hi,

I currently have a program running that handles requests for multiple 
reg-name authorities (thus can originate authoritative responses for 
multiple 'domain names'), in addition the same program can also 
originate authoritative responses to both HTTP and HTTP+TLS requests.

The program (origin-server) accepts entities through POST and PUT, and 
often defines multiple new URIs when a resource is created.

 From HTTPBis p2-semantics-09 section-7.6 | PUT:
   'a PUT request on a general URI might result in several other URIs
    being defined by the origin server.'

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

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?

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

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

 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)

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.

 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?

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?

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?

 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?
  (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?
  (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?

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

Best,

Nathan

---

From: Henrik Nordström <[email-masked]>
Date: Sun, 13 Jun 2010 23:21:33 +0200

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

Any normal URI supporting PUT.

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

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

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

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

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

> given instant, or as indicated by content negotiation might the mapping 

Complex.

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

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

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

>       when the resource identified by the request-target was created?

Yes. But not required to do so.

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

>       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

---

From: Nathan <[email-masked]>
Date: Sun, 13 Jun 2010 22:49:49 +0100

Henrik,

Thank you very much for taking the time thus far, and for the clarifying 
response, it answered all questions and I'd only ask one clarification.. 
as follows:

> representations effectively disabling content negotiation.

In the above scenario, the server supports generating the alternative 
versions for content negotiation - does this come under the banner of 
'implementation specific' and thus allowed, or does it indicate that 
resource is a process that accepts data, and thus POST would have to be 
used rather than PUT. ?

> No apologies needed. Very valid questions.

Best & thanks again,

Nathan

---

From: Henrik Nordström <[email-masked]>
Date: Sun, 13 Jun 2010 23:54:49 +0200

> resource is a process that accepts data, and thus POST would have to be 

Allowed. Implementation specific.

What is not allowed is that the PUT only replaces some representations
of the URI subject to some sever side negotiation.

Regards
Henrik

---

From: Nathan <[email-masked]>
Date: Sun, 13 Jun 2010 22:59:02 +0100

> of the URI subject to some sever side negotiation.

Perfect, thanks :-) my understanding is then that the following is allowed:

- server deletes all representations and create a single new one
- server deletes all representations and creates a new set of 
representations

not allowed:
- server replaces 2 out of 4 representations

If that's correct then no need to reply again,

Best,

Nathan