On Mar 19, 2005, at 4:13 PM, Julian Reschke wrote:
>
> I'd recommend to stick to what RFC2518bis requires.
>
And here's the magic section from 2518bis that says absolutely
everything. Nicely written (from section 7.4):
A lock request to an unmapped URL SHOULD result in the creation of an
locked resource with empty content. A subsequent PUT request with
the correct lock token SHOULD normally succeed, and this new request
provides the content, content-type, content-language and other
information as appropriate.
In this situation, a WebDAV server that was implemented from RFC2518
MAY create "lock-null" resources which are special and unusual
resources. Historically, a lock-null resource:
o Responds with a 404 or 405 to any DAV method except for PUT,
MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.
o Appears as a member of its parent collection.
o Disappears (URI becomes unmapped) if its lock goes away before it
is converted to a regular resource. (This must also happen if it
is renamed or moved, or if any parent collection is renamed or
moved, because locks are tied to URLs).
o May be turned into a regular resource when a PUT request to the
URL is successful. Ceases to be a lock-null resource.
o May be turned into a collection when a MKCOL request to the URL is
successful. Ceases to be a lock-null resource.
o Has defined values for lockdiscovery and supportedlock properties.
However, interoperability and compliance problems have been found
with lock-null resources. Therefore, they are deprecated. WebDAV
servers SHOULD create regular locked empty resources, which are and
behave in every way as normal resources. A locked empty resource:
o Can be read, deleted, moved, copied, and in all ways behave as a
regular resource, not a lock-null resource.
o Appears as a member of its parent collection.
o SHOULD NOT disappear when its lock goes away (clients must
therefore be responsible for cleaning up their own mess, as with
any other operation)
o SHOULD default to having no content type.
o MAY NOT have values for properties like getcontentlanguage which
haven't been specified yet by the client.
Gee, this seems pretty clean and simple. As ghudson said, we're
already disallowing lock-null features in the client. It would be
'KISS' to disable lock-nulls in libsvn_fs altogether, and just teach
mod_dav_svn (and *only* mod_dav_svn) to do the 0-byte PUT thing when a
LOCK comes in from a non-svn client. Once we have that, we end up
* completely compliant with 2518bis
* not having to worry about inefficient listing algorithms
* not having to worry about 'cleaning up' the 0-byte files
* isolating the weirdness to mod_dav_svn alone
* still interoperating with MS Office
This seems like the best of all worlds to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 20 02:11:24 2005