W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2004


From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 12 Jul 2004 09:23:56 +0200
Message-ID: <40F23C8C.7080105@gmx.de>
To: Jason Crawford <ccjason@us.ibm.com>
Cc: Julian Reschke <nnjulian.reschke___at___gmx.de@smallcue.com>, nnw3c-dist-auth___at___w3.org@smallcue.com

Jason Crawford wrote:
>  > > Julian, I can't tell from this what you are recommending a server 
> return
>  > > if (1) a bad token is provided  or (2) no token is provided.  Could you
>  > > please resumarize your conclusions?
>  >
>  > (1) Would be a violation of the precondition DAV:lock-token-matches
>  > 
> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.
>  > section.5.2.1>),
>  > and thus would cause a 4xx status with DAV:error/DAV:lock-token-matches.
>  > The most appropriate 4xx code here seems to be 403 (as there doesn't
>  > seem to be a way to change the state of the resource in a way that the
>  > same request would succeed).
> I can only update the issues list with resolutions that work in the 
> context of 2518.  My copy of 2518 doesn't support much of what you just 
> said.   But it sounds to me that you're recommending 403 as the returned 
> status which is supported.   Have we checked what existing servers 
> return?... or do we just want to go with "SHOULD return 403"? 

Yes, I did: 

This answer *does* work in the context of RFC2518bis; it defines a 
precondition that would need to be added to the spec text.

Speaking of which: it would be really nice if the working group would 
make some progress on the question whether we want to separate locking 
from RFC2518bis. See...:


>  > (2) Is a violation of the request syntax (which requires a Lock-Token
>  > header), thus would result in a plain 400. We *could* add a specific
>  > precondition name for that, but that seems to me like over-engineering.
> Okay.   Have we tested servers?  Or do we just want to go with "SHOULD 
> return 400"?

Yes, we did test servers and their behaviour is inconsistent, thus we 
need to realize that clients MUST handle any 4xx and 5xx response in a 
robust way...:

>  > Anyway, clients MUST be able to properly handle all kinds of 4xx status
>  > codes in a robust manner; so I think it's a bad idea to write specs in a
>  > way that suggest that certain other 4xx codes will never occur.
> Sounds good.

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 12 July 2004 03:24:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:30 UTC