RE: Response marshalling for activity checkin

   From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com]

   "Roy Seto" <Roy.Seto@oracle.com> wrote:

   > How should the response for an activity checkin (as defined by
   > 13.11) be marshalled? 
   > 
   > Should the response code be 201 or 207? Should there be a Location
   > header containing the URL for each new version resource created?
   > Should the response body be a DAV:multistatus element with a
   > DAV:href for each new version resource created?

   Well it isn't defined, so I guess it can be whatever you like<g>.

Yeah, we appeared to have omitted defining this case.
I'm tempted to squeeze something into the final edit pass for this
(assuming we can agree on what it should be :-).

   The only requirement is that:
   "If a response body is included, it MUST be a DAV:checkin-response
   XML element.
       <!ELEMENT checkin-response ANY>"

   The method is being applied to a single resource (the activity) with no 
   depth implications, so a 207 does not 'feel' right.  I realize that there

   are multiple resources affected, but would expect problems with them to
be 
   marshalled in the error response element.

   So if all is well, return '201 Created'.
   I wouldn't return multiple Location: headers.  How would you know which 
   checked-out resource led to which location?

I agree.  Also, you can't return multiple Location headers, because
that would require that the syntax of the Location header allow
a comma separated list, which it does not.

   If there are checkin failures, you could return something like
   409 Conflict

   <DAV:checkin-response>
     <DAV:checkin-activity/>
     <DAV:multi-status>
       <DAV:...
     </DAV:multi-status>
   </DAV:checkin-response>

Note: One of the changes in the final editing pass clarifies that 
DAV:checkin-response is only returned on a successful request.
So a 207 response on failure would be fine, indicating which checkin's
failed (or for servers that support atomic activity checkin, which
checkin's would have failed), and why.  (I assume that like COPY/MOVE,
only the error responses would appear in the 207).

So to make this clear, we would need to say:
- The Location header is not returned on an activity checkin
- If the activity checkin fails, a 207 status must be returned,
  with a response for each checked-out resource that could not
  be checked in.

Does anyone object to this?

Cheers,
Geoff

Received on Thursday, 24 January 2002 17:54:49 UTC