Man, I've got to read the whole RFCs to write an APP server or a client.
You see, people do stupid things like I did if the spec does not explicitly states you SHOULD or shouldn't :-) On 5/9/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
2006/5/9, Toru Marumoto <[EMAIL PROTECTED]>: > > Please be pationt with me, I'm changing my mind a little... > > Let's say, in a introspection document, we have a collection > that accepts "application/atom+xml"(accept both feed doc and entry doc). > <collection > title="Accept multiple entries here" > href="http://example.org/reilly/batch"; > > <accept>application/atom+xml</accept> > </collection> > > So, a client POSTs an Atom Feed Document to the collection > (hoping to create multiple entries). That's not the intended behavior (at least without an explicit extension): if you POST an Atom Feed Document, you expect the whole feed document to be a single resource. At least that's what is being proposed. If you want to do batching POSTing an Atom Feed Document, you need some extension (the server telling the client that it allows such things and the client telling the server that the feed document it is POSTing is intended to be "batch inserts") > What's the value of the Location: header of the response would be? I suppose a 207 (Multi-Status) response could work. http://greenbytes.de/tech/webdav/rfc2518.html#STATUS_207 > Multiple Location: headers for each entry created? (I don't think so) There would be other problems: how will you relate the entries you POSTed to the entries that have been created? There seems to be consensus that servers are allowed to overwrite the atom:id (and other metadata) of the POSTed entries, so there's no mean to identify them and match them between the request and the response. So: it's not worth talking about it without any more thinking. And "batch inserts" can be replaced with multiple POST requests (either using multiple connections, or pipelined into a single "persistent" connection –servers MUST send responses in the same order it received the requests, so you no longer have any problem matching POSTed entries with created/rejected ones–). > Besides, if a client could PUT an Atom Feed Doc to the collection, > we have a Batch operation... Contrary to POST, the semantics of PUT are well-defined and are not meant to "add something" to the target resource but to *replace* the target resource (or create it if it doesn't exist). http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 > This use case suggests (I think) that we should NOT make > "Location header" and "response body as Atom Entry" required. Presence of the Location header in a 201 (Created) response to a POST request is a SHOULD per HTTP/1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 -- Thomas Broyer
