Subject: Appropriate partial success codes (was Re: Some questions about WebDAV)

From: Lisa Dusseault <[email-masked]>
Date: Tue, 11 Oct 2005 17:59:46 -0700

This thread from a couple months ago brought up something probably 
worth clarifying in RFC2518bis.  In fact we could usefully constrain 
servers generally in what status codes MAY or MUST NOT be used inside 
Multi-Status.  I wrote up a strawman draft section for this so we could 
discuss the specifics:

    The following status codes MUST NOT be used in Multi-Status
    responses: 100 Continue, 101 Switching Protocols, 205 Reset Content,
    206 Partial Content, 300 Multiple Choices?, 305 Use Proxy, 400 Bad
    Request, 405 Method Not Allowed, 406 Not Acceptable, 407 Proxy
    Authentication Required, 411 Length Required, 412 Precondition
    Failed, 413 Request Entity Too Large, 414 Request-URI Too Long, 415
    Unsupported Media Type, 416 Requested Range Not Satisfiable, 417
    Expectation Failed, 501 Not Implemented and 505 HTTP Version Not
    Supported.

    The following status codes MAY be used in Multi-Status responses: 200
    OK, 201 Created, 301 Moved Permanently, 302 Found, 303 See Other, 307
    Temporary Redirect, 401 Unauthorized, 403 Forbidden, 404 Not Found
    and 410 Gone.

    The following status codes MAY be used in Multi-Status responses,
    although the meaning might be unclear based only on this
    specification.  Thus, specifications extending WebDAV MAY make use of
    these status codes in Multi-Status responses but regular WebDAV
    clients would reasonably be expected to be confused by these: 202
    Accepted, 203 Non-Authoritative Information, 204 No Content, 304 Not
    Modified, 402 Payment Required, 409 Conflict, 408 Request Timeout,
    500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable
    and 504 Gateway Timeout.

Comments?

Lisa

On Jul 20, 2005, at 11:48 PM, Julian Reschke wrote:

>
> ChunWei Ho wrote:
>> Hi,
>> I have another question. When the If header (webDAV's If header)
>> condition is not met, the request should fail with 412 Precondition
>> Failed. If the request is one over multiple resource, like PROPFIND,
>> COPY or MOVE over Depth > 0, should the whole request fail returning
>> 412 Precondition Failed, or fail only for the specific resources
>> returning 207 MultiStatus with some portions giving a 412 Precondition
>> Failed.
>> Thanks again for the help! :)
>> Regards,
>> CW
>
> Hi,
>
> judging from 
> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.4.p.4>:
>
> "The If header's purpose is to describe a series of state lists. If 
> the state of the resource to which the header is applied does not 
> match any of the specified state lists then the request MUST fail with 
> a 412 (Precondition Failed). If one of the described state lists 
> matches the state of the resource then the request may succeed."
>
> I would say that the server must return a 412 (so partial 
> execution/success of the request is not an option).
>
> Best regards, Julian
>

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 11 Oct 2005 21:42:55 -0400

Some of these are pretty obvious, such as no reason to return a 
multi-status
for something that is independent of the target resource (e.g., 413, 414),
but it would be worth at least a one-liner explaining why these status 
codes
must not be used.

More generally, could you explain what problem this is intended to solve?
A client must be written to cope with status codes it doesn't understand,
in which case it will just look at the first digit.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Oct 2005 08:15:36 +0200

Lisa Dusseault wrote:
> 
> This thread from a couple months ago brought up something probably worth 
> clarifying in RFC2518bis.  In fact we could usefully constrain servers 
> generally in what status codes MAY or MUST NOT be used inside 

Yes.

1) What exactly is the issue this is supposed to solve?

2) How did you come up with these lists? How do they help a client that 
needs to handle unknown status codes anyway (based on the first digit)? 
For instance, why can 300 not appear in a multistatus?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 16 Oct 2005 17:35:20 +0200

Hi,

I note that this paragraph has made it into the current draft at 
<http://ietf.webdav.org/webdav/rfc2518bis/draft-ietf-webdav-rfc2518bis.xml>. 
Could you please remove it unless we reach a working group consensus to 
add it?

Thanks,

Julian

Julian Reschke wrote:
>> Multi-Status.  I wrote up a strawman draft section for this so we 
>> could discuss the specifics:
>>

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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 17 Oct 2005 11:58:34 -0700

Do you really think this should be removed from the final RFC? On the call
the other day I though you were going to do some testing and come up with
some modifications for this text?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 17 Oct 2005 23:35:40 +0200

> some modifications for this text?

No, I think this is a misunderstanding. I really feel this text is both 
misleading, and doesn't resolve any issue I'm aware of.

I'd really like all of us to agree on the approach not to make any 
changes in the original spec unless we have a well-defined issue, and 
working group consensus how to resolve it. If it ain't broke, don't fix it.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 18 Oct 2005 08:06:15 -0400

I agree that this should be removed from the draft text until we have 
consensus that this resolves some significant issue (and like Julian,
I have not seen a compelling argument that it does).

And I agree that changes should not be made to the current draft until 
there
is at least consensus on the mailing list that there is a well-defined 
issue
that needs to be addressed.

Cheers,
Geoff

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 Oct 2005 17:19:07 -0700

> I have not seen a compelling argument that it does).

I have no opinion if this should be there or not and I'm fine if we come to
agreement to remove it. I have fairly good notes from the call and well, no
real point in going there. Needless to say, if we come to agreement on the
list that is the important thing.
 
> And I agree that changes should not be made to the current draft until there
> is at least consensus on the mailing list that there is a well-defined issue

Clearly there is a well define basic issue - the spec if not clear enough on
what implementers should do and/or wrong. That is the main reason we are
doing a bis. We all agree on this. I suspect the author thought this text
was a small clarification to help on this basic issue.

If an author tried to put in some text that they thought would be agreeable
to group to try and make the draft better - well it depends, hopefully big
things they would get WG input on then take a stab at fixing. On small
things they would just fix. It is a judgment call on if something is small
or large. They author will not always get this judgment call right and we as
a group will fix it.

I just don't see how we can finish if the author can't change the document.

Cullen

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 19 Oct 2005 11:52:13 -0700

To respond specifically to the question about resolving issues, the 
text was added in an attempt to comprehensively respond to an issue 
that was raised on the mailing list by ChunWei Ho on July 20.  I 
thought that your answer to ChunWei Ho's question was perfectly 
correct, and that info wasn't unambiguously stated in the RFC, so I 
tried to answer that question and also questions about other status 
codes besides 412 appearing in Multi-Status responses (some of them are 
more subtle than whether or not 412 should appear).  I'm not tied to 
any of the specific recommendations I made in that section -- consider 
it straw-man text.  Have you any changes to recommend in it?

Lisa

On Oct 17, 2005, at 2:35 PM, Julian Reschke wrote:

> No, I think this is a misunderstanding. I really feel this text is 
> both misleading, and doesn't resolve any issue I'm aware of.
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Oct 2005 23:44:11 +0200

Lisa Dusseault wrote:
> 
> To respond specifically to the question about resolving issues, the text 
> was added in an attempt to comprehensively respond to an issue that was 
> raised on the mailing list by ChunWei Ho on July 20.  I thought that 
> your answer to ChunWei Ho's question was perfectly correct, and that 
> info wasn't unambiguously stated in the RFC, so I tried to answer that 
> question and also questions about other status codes besides 412 
> appearing in Multi-Status responses (some of them are more subtle than 
> whether or not 412 should appear).  I'm not tied to any of the specific 
> recommendations I made in that section -- consider it straw-man text.  
> Have you any changes to recommend in it?
> 
> Lisa

The question was:

"Hi,

Regards,
CW"

(see 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JulSep/0070.html>).

I'm not sure how the new text you added helps resolving that, because 
this was about whether to return a 207 or not.

My answer was:

"Hi,

judging from

"The If header's purpose is to describe a series of state lists. If the
state of the resource to which the header is applied does not match any
of the specified state lists then the request MUST fail with a 412
(Precondition Failed). If one of the described state lists matches the
state of the resource then the request may succeed."

I would say that the server must return a 412 (so partial
execution/success of the request is not an option)."

(see 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JulSep/0071.html>)

So as far as I can tell the spec is perfectly ok, and there's absolutely 
no reason to add any new text because of this question.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 19 Oct 2005 23:13:43 -0400

I agree with Julian.

Here's a good example of why if you think you have a paragraph that
addresses some concern, please just email it out and say "how about this 
paragraph to resolve issue XYZ" (ideally, with a URL to the bug or email
message for issue XYZ).  That is far easier to review than to hope Julian
catches the change and brings it to our attention on the mailing list.

Cheers,
Geoff

> > To respond specifically to the question about resolving issues, the 
text

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 19 Oct 2005 15:26:17 -0700

Well, I suppose there are multiple ways of answering the question.    
Since the question explicitly asked whether the server should fail  
"returning 207 Multi-Status with some portions giving a 412  
Precondition Failed", I still find that saying that 412 can't appear in  
Multi-Status is at least a partial answer to that question.

Another answer would be to say that unmet preconditions MUST cause the  
entire request to fail atomically even if the request involves multiple  
resources.  Do you think we should add that to the draft?

Lisa

On Oct 19, 2005, at 2:44 PM, Julian Reschke wrote:

>> codes besides 412 appearing in Multi-Status responses (some of them  
>> are more subtle than whether or not 412 should appear).  I'm not tied  
>> to any of the specific recommendations I made in that section --  
>> consider it straw-man text.  Have you any changes to recommend in it?
>> Lisa
>
> The question was:
>
> "Hi,
>
> So as far as I can tell the spec is perfectly ok, and there's  
> absolutely no reason to add any new text because of this question.
>
> Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Oct 2005 21:08:37 +0200

> Multi-Status is at least a partial answer to that question.

...but:

1) A statement about 412 in multistatus is very different from adding a 
whole new section saying lots of other things, and

2) from a procedural p.o.v.: somebody asked a question, and there was a 
single answer, and no further discussion. To me, cases like this one are 
a perfect example for no changes of the spec being required. We 
shouldn't change the spec each and every time somebody has a question 
unless there's a consensus that there's actually something wrong with 
the spec. If it ain't broken, don't fix it.

> resources.  Do you think we should add that to the draft?

After re-reading the thread I actually think that RFC2518 currently 
defines a behaviour for "Depth" that is unlikely to be implemented. So 
what we need to do is to sit down, write test cases and find out what 
current implementations do. *Then*, wen can discuss potential changes. 
But please let's first find out what currently servers do.

Volunteers?

Best regards, Julian