2006/5/15, James M Snell <[EMAIL PROTECTED]>:
I don't think so. In our implementation, our feeds are access controlled. Someone may have post permission, but may not have read permission, meaning that what they post would not show up in their feed and would return a Forbidden if they attempted to GET it. The one odd thing about it would be the fact that the server would have to return a Location but the user can't use it for anything.
If the newly-created resource is not identified by a URI, then just return 200 (OK) or 204 (No Content) instead of 201 (Created). This is what I understand from section 9.5 POST of HTTP/1.1: "The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result." However, if the newly-created resource is identified by a URI, then a 201 (Created) SHOULD be sent back along with a Location header, whether or not the user has access to it or not. Per HTTP/1.1, if access can be granted depending on credentials, then 401 (Unauthorized) should be sent, otherwise 403 (Forbidden) is fine. I think a server shouldn't however return a 201 (Created) where the URI given in the Location header will always return 404 (Not Found). Otherwise, wrt Tim's scenario, see this discussion from last summer: http://www.imc.org/atom-protocol/mail-archive/msg01384.html In particular, this paragraph from a mail in the discussion: "Client implementors should be aware that a Collection Resource might not accept GET but still accept POST, and adapt their client behavior accordingly (not telling you "this is not an APP entry point" but rather "you're not allowed to list the resources in this collection" (depending on the 4xx status code returned, off course))." [http://www.imc.org/atom-protocol/mail-archive/msg01387.html] This should be a use case supported by the core protocol, using either a per-entry or global comments collection (à la W3C's Annotate). Global comments collection would require the Feed Threading Extension though. See http://www.imc.org/atom-protocol/mail-archive/msg01385.html about the "global collection" approach. -- Thomas Broyer
