- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 24 Jan 2003 23:03:43 +0100
- To: <w3c-dist-auth@w3c.org>
Well, if we're trying to achieve consistency, we should try do it consistently. Returning a multistatus with a non-207 status in just one specific case seems like a workaround, not a fix. BTW: DELETE is always "depth infinity" -- there is no shallow DELETE. As far as I can tell, this would affect all namespace operations, such as COPY, MOVE, DELETE and possibly LOCK. In general, this would enable clients to do the HTTP-sanctioned range checks (status >= 200 && status <= 299). Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Friday, January 24, 2003 10:49 PM > To: 'Julian Reschke'; 'John DeSoi'; w3c-dist-auth@w3c.org > Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and > INTEROP_DELETE_AND_MULTISTATUS > > > > > That being said, from a consistency p.o.v. I agree. I'll > > assume for a moment > > that few WebDAV clients indeed *do* evaluate a 207 on DELETE > > (and other > > candidates such as LOCK/COPY...), and those probably would be easy to > > upgrade. If this is true, all we'd need to do is > > > > - deprecate status of 207 for failures > > - introduce a new 4xx code such as INCOMPLETE OPERATION which > > would carry > > the same multistatus body > > > It doesn't seem nearly that big a change is necessary. The biggest > change I'd consider given what I currently know, is that the spec would > require that HTTP 1.1 method requests to non-collections should not > result in 207. This would only affect the definition for DELETE, since > that's the only HTTP 1.1 method that is defined defined as returning > 207. DELETE could still return 207 in response to a Depth: infinity > request to a collection. > > My reasoning is that HTTP clients address individual pages with DELETE > requests, not collections. > > lisa > >
Received on Friday, 24 January 2003 17:04:30 UTC