Subject: WebDAV sync report w/invalid sync token

From: Ken Murchison <[email-masked]>
Date: Tue, 15 Nov 2011 08:32:39 -0500

Folks,

What is the proper response code for a sync-collection report if the 
sync-token is either invalid or out of date?  The I-D doesn't seem to 
specify, so looking at RFC 3253 section 1.6 it appears that 403 and 409 
are the two options for a precondition failure, with 409 presumably 
being the correct choice in this case.  Am I missing something?

Thanks,
Ken

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Werner Donné <[email-masked]>
Date: Tue, 15 Nov 2011 15:03:11 +0100

Hi Ken,

Your conclusion is correct, because the draft uses the REPORT method, which
is specified in RFC 3253. However, the draft doesn't refer to this RFC.
This would probably be difficult, because synchronization is supposed to
work as well for servers and clients that don't implement RFC 3253. Some
day the generic stuff in RFC 3253 should move to a separate RFC or perhaps
RFC 4918.

Best regards,

Werner.

On Tue, Nov 15, 2011 at 2:32 PM, Ken Murchison <[email-masked]> wrote:

> specify, so looking at RFC 3253 section 1.6 it appears that 403 and 409 are
> the two options for a precondition failure, with 409 presumably being the
> correct choice in this case.  Am I missing something?
>
> Thanks,
> Ken
>
> --
> Kenneth Murchison

-- 
http://www.pincette.biz/
Handling your documents with care, wherever you are.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 15 Nov 2011 09:26:06 -0500

Hmm.  Not having a normative reference to RFC 3253 might be an 
oversight.  Without the draft explicitly stating that 409 should be used 
for an invalid sync-token or having an example showing as much, RFC 3253 
is the only way for implementers to know what response code is applicable.

Werner Donné wrote:
> Hi Ken,
> 
> Your conclusion is correct, because the draft uses the REPORT method, 
> which is specified in RFC 3253. However, the draft doesn't refer to this 
> RFC. This would probably be difficult, because synchronization is 
> supposed to work as well for servers and clients that don't implement 
> RFC 3253. Some day the generic stuff in RFC 3253 should move to a 
> separate RFC or perhaps RFC 4918.
> 
> Best regards,
> 
> Werner.
> 
> On Tue, Nov 15, 2011 at 2:32 PM, Ken Murchison <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Folks,
> 
>     sync-token is either invalid or out of date?  The I-D doesn't seem
>     to specify, so looking at RFC 3253 section 1.6 it appears that 403
>     and 409 are the two options for a precondition failure, with 409
>     presumably being the correct choice in this case.  Am I missing
>     something?
> 
>     Thanks,
>     Ken
> 
>     -- 
>     Kenneth Murchison

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 15 Nov 2011 09:59:32 -0500

Hi Ken,

--On November 15, 2011 8:32:39 AM -0500 Ken Murchison 
<[email-masked]> wrote:

> are the two options for a precondition failure, with 409 presumably being
> the correct choice in this case.  Am I missing something?

I prefer to return 403's for all errors that involve pre-conditions and 
that contain the DAV:error element.

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Tue, 15 Nov 2011 10:06:45 -0500

> that contain the DAV:error element.

Thanks Cyrus.

I can see the logic there.  So we want to tell the client to not repeat 
the request with the same sync-token as opposed to telling it that the 
request may work as-is once some other unspecified conflict is resolved.

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 15 Nov 2011 10:13:51 -0500

Hi Ken,

> request may work as-is once some other unspecified conflict is resolved.

Well any client using the sync REPORT should be looking at the DAV:error 
element and the behavior for that is explicitly described in the spec. If 
DAV:error were not present, then the client would follow the "normal" rules 
for HTTP status code processing.

-- 
Cyrus Daboo

---

From: Evert Pot <[email-masked]>
Date: Tue, 15 Nov 2011 16:32:52 +0100

On 2011-11-15, at 4:13 PM, Cyrus Daboo wrote:

> Hi Ken,
> 
> --On November 15, 2011 10:06:45 AM -0500 Ken Murchison <[email-masked]> wrote:
> 
> Well any client using the sync REPORT should be looking at the DAV:error element and the behavior for that is explicitly described in the spec. If DAV:error were not present, then the client would follow the "normal" rules for HTTP status code processing.

I'd be nice if the spec authors could explicitly state an http error code for every error condition. I don't think leaving it open to interpretation (or unclear.. have your pick) is a good thing.

Evert

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Nov 2011 17:02:04 +0100

On 2011-11-15 16:32, Evert Pot wrote:
> ...
> ...

That can be dangerous, as it could trick developers to think that these 
are the only codes that need to be handled... So the spec would need to 
make clear that these are just examples/suggestions...

Best regards, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 15 Nov 2011 11:23:34 -0500

Hi Julian,

--On November 15, 2011 5:02:04 PM +0100 Julian Reschke 
<[email-masked]> wrote:

>> I'd be nice if the spec authors could explicitly state an http error
>> code for every error condition. I don't think leaving it open to
>> interpretation (or unclear.. have your pick) is a good thing. ...
>

Which is exactly what the WebDAV base spec describes for 
pre-/post-conditions, hence the fact that no other WebDAV extension 
documents explicitly list a status code. Plus the distinction between some 
codes is not always clear - we could argue for a long time over whether 403 
or 409 should be returned for an invalid sync token.

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Nov 2011 17:31:39 +0100

On 2011-11-15 17:23, Cyrus Daboo wrote:
> documents explicitly list a status code. Plus the distinction between
> some codes is not always clear - we could argue for a long time over
> whether 403 or 409 should be returned for an invalid sync token.

Indeed; the HTTP status code mainly is for components that do not know 
about WebDAV. Those who do should inspect DAV:error.

Best regards, Julian