Subject: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and INTEROP_DELETE_AND_MULTISTATUS

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 21 Jan 2003 21:06:26 -0800

Issue PUT_AND_INTERMEDIATE_COLLECTIONS: this issue was a request to
allow PUT to create intermediate collections. I believe there is no
consensus to do this and we should resolve this wont' fix.

Issue INTEROP_DELETE_AND_MULTISTATUS: this issue is a request for DELETE
errors to be 4xx so that HTTP clients don't think 207 is a success.
That's no longer really an issue - few HTTP clients do authoring, and
those that do are at least aware that 207 is a multistatus response and
not a complete success. We should resolve this won't fix.

Considering only the meeting attendees today, there's consensus so far.

lisa

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 21 Jan 2003 23:47:54 -0800

> Issue INTEROP_DELETE_AND_MULTISTATUS: this issue is a request for 
> DELETE errors to be 4xx so that HTTP clients don’t think 207 is a 
> success. That’s no longer really an issue – few HTTP clients do 
> authoring, and those that do are at least aware that 207 is a 
> multistatus response and not a complete success. We should resolve 
> this won’t fix.

Doing that violates the HTTP protocol, not WebDAV.

....Roy

---

From: Bob Denny <[email-masked]>
Date: Wed, 22 Jan 2003 08:16:45 -0700

Lisa Dusseault:
> few HTTP clients do authoring, and those that do are at least aware that
> 207 is a multistatus response

Netscape/Mozilla Composer is an HTTP authoring tool that is not aware of 207.

> Doing that violates the HTTP protocol, not WebDAV.

Yes, and let's not.

  -- Bob

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 22 Jan 2003 16:39:09 +0100

But then, HTTP does not define the concept of collections and deep deletes.
WebDAV is an extension of HTTP, so when it introduces these new concepts,
isn't it allowed also to define error handling for it?

Yes, there's an issue with using a 2xx status for errors, but it doesn't
seem to have negatively affected any existing client I'm aware of.
RFC2518bis is supposed to clarify RFC2518, not to reinvent it.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Roy T. Fielding
> Sent: Wednesday, January 22, 2003 8:48 AM
> To: Lisa Dusseault
> Cc: 'Webdav WG'
> Subject: Re: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_AND_MULTISTATUS
>
>
>

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 22 Jan 2003 16:49:41 +0100

> [mailto:[email-masked]]On Behalf Of Bob Denny
> Sent: Wednesday, January 22, 2003 4:17 PM
> To: [email-masked]

Yes. But as far as I understand it's abandoned as well. The solution here is
to make sure that when/if Mozilla 1.x starts supporting authoring again, it
will pay attention to RFC2518 semantics.

I think your comments show a misunderstanding of the RFC process here.
RFC2518 is being revised. Things that don't work or haven't been
interoperably supported are thrown out. Things that need to be clarified are
clarified. That's it.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 22 Jan 2003 12:14:22 -0800

> RFC2518bis is supposed to clarify RFC2518, not to reinvent it.

WebDAV can add new status codes.  It cannot redifine the meaning of 2xx
status codes.  Doing so destroys one of the main extensibility
mechanisms of HTTP.

It negatively affects any client that proceeds with later actions
based on the status being successful.  WebDAV hasn't seen it yet
because it is still working on first-generation systems and performance
is not yet a deciding factor between implementations.

....Roy

---

From: John DeSoi <[email-masked]>
Date: Thu, 23 Jan 2003 08:24:47 -0500

>will pay attention to RFC2518 semantics.

Netscape/Mozilla still supports editing with Composer and works fine 
with my WebDAV server (using HTTP PUT). I don't believe it supports a 
DELETE method; but since HTTP does define a DELETE method, I don't 
see how WebDAV can justify redefining the meaning of 2xx status codes.

Best,

John DeSoi, Ph.D.

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 24 Jan 2003 19:18:52 +0100

> [mailto:[email-masked]]On Behalf Of John DeSoi
> Sent: Thursday, January 23, 2003 2:25 PM
> Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and

You are right. For some reason I thought that this was supposed to work
using "save", which was greyed out when a web resource was opened. In fact,
it's "Publish". You learn something new every day.

> see how WebDAV can justify redefining the meaning of 2xx status codes.

Well. The main justification is that it has been doing this for almost 4
years now, and

- there wasn't a big outcry, and
- it doesn't seem to negatively affect anybody.

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

Feedback appreciated.

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 24 Jan 2003 13:49:01 -0800

> 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

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 24 Jan 2003 23:03:43 +0100

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

> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: Friday, January 24, 2003 10:49 PM
> To: 'Julian Reschke'; 'John DeSoi'; [email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 24 Jan 2003 23:13:25 +0100

OK,

here's my proposal then:

1) define:

425 Incomplete Operation
The 425 (Incomplete Operation) status code means that the method could not
be performed completely because it wasn't executed atomically and the
request could not be applied to all affected child resources.

2) deprecate marshalling of multistatus with 207 on failures or incomplete
operations

3) allow multistatus response body for 424 (failed dependancy) and 425.

Note that 424 could be used when the whole operations was rejected because
of an error on a child resource (such as deep locks that are in conflict
with child lock -- another open issue for error marshalling), while 425
would be returned when the method "partly" succeeded (like a DELETE that
couldn't remove one specifc child, but many others).

Julian

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault