2006/5/10, Mark Baker <[EMAIL PROTECTED]>:
I can live with "SHOULD" on a response body being returned. But why MUST it be an Atom entry? When you were trying to force a return of the (possibly modified) requested entry on the response, that made some sense since the request was an Atom entry. But without that it just seems to limit extensibility for no good reason, AFAICT... as I've described before.
+1 This implies conflicts with HTML-form-driven POST's or 2-Way-RSS when you want to support them at the same URI.
To be good HTTP clients, they should be checking the Content-Type header anyway, right? You wouldn't want them assuming it was application/atom+xml just because a non-HTTP spec said so. So I could live with "SHOULD be an Atom entry".
-1 I'd however be +1 to suggesting this as an optimization trick for server implementers, in the sense that clients won't have to issue a GET just after the POST/PUT response. In any case, there must be something like "clients MUST NOT assume a returned Atom Entry Document representes the newly created resource unless there is a Content-Location whose value is identical character-by-character (after relative-URI resolution) to the Location header value". I could live without the "after relative-URI resolution" part if this is made clear that clients are allowed to expect only absolute-URIs for comparison (i.e. if this is a relative URI, it will never be identical character-by-character to the Location header, as this one must have an absolute-URI value). -- Thomas Broyer
