headers
Evert | Rooftop | 5 Nov 2008 04:10
Picon
Favicon
Gravatar

delete & unlock on previously locked resources

Hi Guys,

Litmus 0.12 added tests for locking unmapped urls. One of the tests is  
failing for me, and I have a feeling it might be a bug in litmus, so I  
wanted to ask here..

test 38: unmapped_lock
* LOCK /litmus/unmapped_url (i respond with 201 Created)
* DELETE /litmus/unmapped_url (i respond with 204 No Content)

test 39: unlock
* UNLOCK /litmus/unmapped_url

I fail the last unlock with 412 Precondition failed

Would 412 be the correct response in this case?

Thanks!
Evert
Attachment (smime.p7s): application/pkcs7-signature, 2433 bytes
Permalink | Reply | 5 comments |
headers
Julian Reschke | 5 Nov 2008 10:09
Picon
Picon

Re: delete & unlock on previously locked resources


Evert | Rooftop wrote:
> Hi Guys,
> 
> Litmus 0.12 added tests for locking unmapped urls. One of the tests is 
> failing for me, and I have a feeling it might be a bug in litmus, so I 
> wanted to ask here..
> 
> test 38: unmapped_lock
> * LOCK /litmus/unmapped_url (i respond with 201 Created)
> * DELETE /litmus/unmapped_url (i respond with 204 No Content)
> 
> test 39: unlock
> * UNLOCK /litmus/unmapped_url
> 
> I fail the last unlock with 412 Precondition failed
> ...

Shouldn't that be a 404?

Please post the full trace (a 412 is only correct if there's a 
conditional header involved).

BR, Julian
Permalink | Reply | 1 comment |
headers
Evert | Rooftop | 5 Nov 2008 16:19
Picon
Favicon
Gravatar

Re: delete & unlock on previously locked resources

On 5-Nov-08, at 4:09 AM, Julian Reschke wrote:

>
> Evert | Rooftop wrote:
>> Hi Guys,
>> Litmus 0.12 added tests for locking unmapped urls. One of the tests  
>> is failing for me, and I have a feeling it might be a bug in  
>> litmus, so I wanted to ask here..
>> test 38: unmapped_lock
>> * LOCK /litmus/unmapped_url (i respond with 201 Created)
>> * DELETE /litmus/unmapped_url (i respond with 204 No Content)
>> test 39: unlock
>> * UNLOCK /litmus/unmapped_url
>> I fail the last unlock with 412 Precondition failed
>> ...
>
> Shouldn't that be a 404?
>
> Please post the full trace (a 412 is only correct if there's a  
> conditional header involved).
>
> BR, Julian
>

A 404 makes more sense, but that also made the litmus test fail. Here  
are the relevant headers (took out the unneeded stuff)

LOCK /litmus/unmapped_url HTTP/1.1
Depth: 0
Timeout: Second-3600
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Orton | 5 Nov 2008 16:26
Picon

Re: delete & unlock on previously locked resources


On Tue, Nov 04, 2008 at 10:10:17PM -0500, Evert | Rooftop wrote:
> Litmus 0.12 added tests for locking unmapped urls. One of the tests is  
> failing for me, and I have a feeling it might be a bug in litmus, so I  
> wanted to ask here..

Hiya, yes, this is a litmus bug; it'll be fixed for the next release; 
see this thread:

http://lists.manyfish.co.uk/pipermail/litmus/2008-October/000009.html

Regards, Joe
Permalink | Reply | 2 comments |
headers
Evert | Rooftop | 5 Nov 2008 16:29
Picon
Favicon
Gravatar

Re: delete & unlock on previously locked resources

Thanks a lot Joe, so just to confirm.. The appropriate response would  
be 404 here, right?

Evert

On 5-Nov-08, at 10:26 AM, Joe Orton wrote:

>
> On Tue, Nov 04, 2008 at 10:10:17PM -0500, Evert | Rooftop wrote:
>> Litmus 0.12 added tests for locking unmapped urls. One of the tests  
>> is
>> failing for me, and I have a feeling it might be a bug in litmus,  
>> so I
>> wanted to ask here..
>
> Hiya, yes, this is a litmus bug; it'll be fixed for the next release;
> see this thread:
>
> http://lists.manyfish.co.uk/pipermail/litmus/2008-October/000009.html
>
> Regards, Joe
>
Attachment (smime.p7s): application/pkcs7-signature, 2433 bytes
Permalink | Reply | 0 comments |
headers
Julian Reschke | 5 Nov 2008 16:38
Picon
Picon

Re: delete & unlock on previously locked resources


Joe Orton wrote:
> On Tue, Nov 04, 2008 at 10:10:17PM -0500, Evert | Rooftop wrote:
>> Litmus 0.12 added tests for locking unmapped urls. One of the tests is  
>> failing for me, and I have a feeling it might be a bug in litmus, so I  
>> wanted to ask here..
> 
> Hiya, yes, this is a litmus bug; it'll be fixed for the next release; 
> see this thread:
> 
> http://lists.manyfish.co.uk/pipermail/litmus/2008-October/000009.html

I see. Yes, that's a bug.

I missed that there was a new release :-)

BR, Julian
Permalink | Reply | 0 comments |
headers
Julian Reschke | 5 Nov 2008 16:50
Picon
Picon

Re: unclear on shared lock support


Joe Orton wrote:

> On Mon, Nov 03, 2008 at 11:50:08PM -0800, John Meissen wrote:
>> I consider shared vs exclusive to be a lock attribute. There are other
>> requested attributes, like timeout, that a server is free to ignore.
>> I interpreted the RFC as allowing me to ignore the request to make the
>> lock shared, and permitting me to create the lock in the mode I support
>> (exclusive), especially since the actual lock characteristics are 
>> detailed in the response body. Hence there shouldn't be any confusion
>> on the client's part since it can see what type of lock was created.
> 
> Hmmm, interesting.
> 
> I agree that neon/litmus should check that the lock returned by LOCK 
> matches the lock type requested, and fail/skip subsequent shared lock 
> tests appropriately.
> 
> But I don't agree that it's a valid interpretation of 4918 to downgrade 
> the lock type from exclusive to shared.  There is specific language in 
> 4918 explaining that the timeout is a "suggestion" made by the client - 
> there is no such language in the section on the lock type.

Right.

> If you can get consensus on the DAV list (w3c-dist-auth at w3.org) that 
> this behaviour is to be permitted then I'll update litmus to SKIP rather 
> than FAIL if the shared lock request is downgraded.

No, I don't think this would be correct.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 5 Nov 2008 23:01
Picon
Picon

Re: unclear on shared lock support


John Meissen wrote:
>> No, I don't think this would be correct.
>>
>> If a server doesn't allow shared locks, it should reject the request. 
>> That's it.
>>
>> And yes, making Litmus smarter with respect to shared lock functionality 
>> would be good.
>>
>> Best regards, Julian
>>
> 
> On the other hand, while there is explicit language detailing what other
> conditions constitute failure there is nothing about shared vs exclusive.
> And it's not clear to me that any of the listed potential responses would
> fit such a failure.

That list is not exhaustive. From 
<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.9.11.1>:

"In addition to the general status codes possible, the following status 
codes have specific applicability to UNLOCK:"

In general, when a client sends a request, and the server can't fulfill 
it, it has to return an appropriate failure code, and *not* do something 
else.

The timeout value is a special case, and that's why the spec says so.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Julian Reschke | 9 Nov 2008 16:51
Picon
Picon

Last minute changes to WebDAV SEARCH, was: WebDAV SEARCH approved as Proposed Standard


Hi,

I've been working with the RFC Editor on the publication of this 
specification, and some disagreements surfaced with respect how to cite 
historic Internet Drafts, and what type of URLs are (or should be) 
acceptable in an RFC. People interested in the discussion itself may 
want to read the archives of the rfc-interest mailing list (starting 
with 
<http://mailman.rfc-editor.org/pipermail/rfc-interest/2008-October/000888.html>).

To get the issue resolved, I have moved the historic references to the 
Contributors section, and changed the document URLs to use purl.org as 
indirection mechanism (the RFC Editor was concerned with the stability 
of URLs on www.webdav.org...).

So Section 1.1 now starts with:

1.1.  DASL

    This document defines Web Distributed Authoring and Versioning
    (WebDAV) SEARCH, an application of HTTP/1.1 forming a lightweight
    search protocol to transport queries and result sets that allows
    clients to make use of server-side search facilities.  It is based on
    earlier work done in the IETF DASL Working Group (see Section 10).
    In this specification, the terms "WebDAV SEARCH" and "DASL" are used
    interchangeably. --

<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.1.1>,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 10 Nov 2008 14:14
Picon
Picon

Mapping DAV link properties to HTML/Atom/Http link relations


Hi,

some while ago, the Atom feed format has introduced link relations that 
either can use a short name (through an IANA registry), or a full URI as 
identifier. 
<http://tools.ietf.org/html/draft-nottingham-http-link-header-02> 
generalizes this concept, introducing a single registry for both (X)HTML 
and Atom link relations, and also re-introduces the HTTP Link header 
(defined in RFC 2068, but dropped from RFC 2616).

In WebDAV, we already have properties of type link implicitly (by 
containing DAV:href elements). So, for instance, the DAV:checked-in 
property defined in 
<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.2.1>, could 
be interpreted to also define a link relation identified by the URI 
"DAV:checked-in".

Potential benefits:

1) Use in HTTP Link Header

A server could expose the property value in an HTTP response header, 
independently of WebDAV:

HEAD /foobar HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/plain
(Continue reading)

Permalink | Reply | 0 comments |

Gmane