Re: BugZilla issue 227: collection state

+1

Julian Reschke wrote:
> 
> Hi,
> 
> below are proposed changes for Section 5, resolving Bugzilla issue 227 
> (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=227>) and 
> applying editorial fixes:
> 
> 
> Section 5.1., para. 2:
> OLD:
> 
>    An HTTP URL namespace is said to be consistent if it meets the
>    following conditions: for every URL in the HTTP hierarchy there
>    exists a collection that contains that URL as an internal member.
>    The root, or top-level collection of the namespace under
>    consideration, is exempt from the previous rule.  The top-level
>    collection of the namespace under consideration is not necessarily
>    the collection identified by the absolute path '/', it may be
>    identified by one or more path segments (e.g. /servlets/webdav/...)
> 
> NEW:
> 
>    An HTTP URL namespace is said to be consistent if it meets the
>    following conditions: for every URL in the HTTP hierarchy there
>    exists a collection that contains that URL as an internal member URL.
>    The root, or top-level collection of the namespace under

Re: BugZilla issue 213: PROPFIND consistencies

+1

Julian Reschke wrote:
> 
> Hi,
> 
> the proposed patches below fixes several problems with PROPFIND, some of 
> which were recorded in BugZilla issue 213 
> (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=213>):
> 
> 
> Section 9.1., para. 2:
> OLD:
> 
>    A client MUST submit a Depth header with a value of "0", "1", or
>    "infinity" with a PROPFIND request.  Servers MUST support "0" and "1"
>    depth requests on WebDAV-compliant resources and SHOULD support
>    "infinity" requests.  In practice, support for depth infinity
>    requests MAY be disabled, due to the performance and security
>    concerns associated with this behavior.  Since clients weren't
>    required to include the Depth header in [RFC2518], servers SHOULD
>    treat such a request as if a "Depth: infinity" header was included.
> 
> NEW:
> 
>    A client may submit a Depth header with a value of "0", "1", or
>    "infinity" with a PROPFIND request.  Servers MUST support "0" and "1"
>    depth requests on WebDAV-compliant resources and SHOULD support
>    "infinity" requests.  In practice, support for depth infinity

Fwd: I-D ACTION:draft-reschke-webdav-mount-04.txt

Hi,

this revision updates the MIME type registration ti use the RFC4288 
template (see marked up changes in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-mount-04.html>).

Note that this draft has been sitting in the RFC Editor queue for 
several months, just to find out that it needs to go through IESG first 
because of the MIME type registration in the IETF tree. If somebody has 
an idea about how I can get the IESG to follow up, I'm all ears (given 
the fact that we have at least two IESG members on the mailing list, I 
thought this would be worth mentioning...).

Best regards, Julian

Internet-Drafts <at> ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Mounting Web Distributed Authoring and Versioning (WebDAV) servers
> 	Author(s)	: J. Reschke
> 	Filename	: draft-reschke-webdav-mount-04.txt
> 	Pages		: 17
> 	Date		: 2006-5-1
> 	
> In current Web browsers, there is no uniform way to specify that a
> user clicking on a link will be presented with an editable view of a
> WebDAV server.  For example, it is frequently desirable to be able to
> click on a link, and have this link open a window that can handle

New mini WebDAV server

Re: New mini WebDAV server

Wilfred wrote:
> We have just released a new WebDAV plugin for our server. The beta 
> version can be downloaded from:
> http://barracudaserver.com/examples/BarracudaDrive/WebDAV.html
>  
> We have so far tested the server with davfs2, Mac OS X, WebDrive, Web 
> Folders, and MS MiniRedir.
>  
> The server accepts the MS domain name prefix and can authenticate using 
> either Basic or Digest. It should therefore be easy to use with 
> MiniRedir, which requires Digest authentication i.e. you do not have to 
> mess with the registry. We have however seen that MiniRedir fails to 
> authenticate on some computers, but works on others even though the 
> MiniRedir version appears to be the same on the computers we tested it 
> on. Let me know if anyone would like to see the MiniRedir HTTP trace 
> when it fails to authenticate.

I think auth behavior for MiniRedir may depend on registry settings 
(those also control whether it allows Basic). I have no other pointers, 
so you may have to google for that info...

> The purpose with the WebDAV plugin is to make it possible to mount 
> embedded devices as a remote disk. The locking in DAV 2 is partly 
> implemented in order to make it interoperate with "drive" clients 
> requiring locking. A "drive" client such as davfs2 can then be mounted 
> as a drive.
>  
> As far as we see, locking in not a feature embedded devices need. It 
> adds unnecessary complexity to the server. It also requires runtime 
> resources and is costly to process.
>  
> A WebDAV "drive" client should interoperate with a standard DAV 1 server.

I agree here. It would be interesting to understand why client 
implementations actually request a lock (well, except if the application 
opening the file indeed asked for a file lock).

Best regards, Julian

Re: New mini WebDAV server

RE: New mini WebDAV server

Re: getcontentlength property

Werner Donné wrote:
> Hi,
> 
> RFC 2518 says that the getcontentlength property is mandatory if
> the resource returns the Content-Length header in response to a GET.
> 
> In a servlet container you don't always know if that header will
> be in the response. Normally a document is streamed to the response
> body. The container sees this because of the intermediate flushes.
> It will then use the chunked transfer encoding. It can be, however,
> that the document is smaller than the internal streaming buffer.
> There are no intermediate flushes then and the container may choose
> to not use a transfer encoding, in which case the Content-Length
> header will be set.
> 
> It is also an expensive operation if the document is versioned and
> must be reconstructed from a delta file.

Agreed, there are cases where a WebDAV server implementor simply doesn't 
have any control over this. Therefore the MUST level requirement should 
be relaxed to a SHOULD.

Best regards, Julian

(cc:ing the WebDAV WG mailing list, because this happens not to be a 
Versioning question)

Re: getcontentlength property

Julian Reschke wrote:
> 
> Werner Donné wrote:
>> Hi,
>>
>> RFC 2518 says that the getcontentlength property is mandatory if
>> the resource returns the Content-Length header in response to a GET.
>>
>> In a servlet container you don't always know if that header will
>> be in the response. Normally a document is streamed to the response
>> body. The container sees this because of the intermediate flushes.
>> It will then use the chunked transfer encoding. It can be, however,
>> that the document is smaller than the internal streaming buffer.
>> There are no intermediate flushes then and the container may choose
>> to not use a transfer encoding, in which case the Content-Length
>> header will be set.
>>
>> It is also an expensive operation if the document is versioned and
>> must be reconstructed from a delta file.
> 
> Agreed, there are cases where a WebDAV server implementor simply doesn't 
> have any control over this. Therefore the MUST level requirement should 
> be relaxed to a SHOULD.
> 
> Best regards, Julian
> 
> (cc:ing the WebDAV WG mailing list, because this happens not to be a 
> Versioning question)

Added as issue to BugZilla: 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=239>.

Best regards, Julian

Re: Bug 143 (lock refresh), was: WGLC of draft-ietf-webdav-rfc2518bis-14.txt

I'm really not at all sure we ever decided to do this.  Julian asked  
the WG on Feb 20 which way we should go on this, and nobody answered.

Even assuming that we agree to go back to using "if" header to  
refresh locks, there are some problems with the changes proposed
  - requires refreshing *multiple* locks with one request, which  
RFC2518 doesn't clearly require, so if we're reverting for the sake  
of backward-compatibility, that's no good.
  - the precondition change isn't consistent with precondition use  
for other cases, because a lock token was provided.

Lisa

On Feb 26, 2006, at 11:46 AM, Julian Reschke wrote:

> Cullen Jennings wrote:
> > ..
>> On minor issues, Julian will be proposing new text for bug 143.
>> ..
>
> ...did that. Summary in <http://lists.w3.org/Archives/Public/w3c- 
> dist-auth/2006JanMar/0670.html>, proposed text in <http:// 
> ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143#c11>, and below:
>
> Section 9.10.2., para. 1:
> OLD:
>
>     A lock is refreshed by sending a LOCK request to the URL of a
>     resource within the scope of the lock.  This request MUST NOT  
> have a
>     body and it MUST specify which lock to refresh by using the 'Lock-
>     Token' header with a single lock token (only one lock may be
>     refreshed at a time).  It MAY contain a Timeout header, which a
>     server MAY accept to change the duration remaining on the lock  
> to the
>     new value.  A server MUST ignore the Depth header on a LOCK  
> refresh.
>
> NEW:
>
>     A lock is refreshed by sending a LOCK request to the URL of a
>     resource within the scope of the lock.  This request MUST NOT  
> have a
>     body and it MUST specify which lock to refresh by submitting the
>     corresponding lock token in the 'If' request header (see
>     Section 10.4).  It MAY contain a Timeout header, which a server  
> MAY
>     accept to change the duration remaining on the lock to the new  
> value.
>     A server MUST ignore the Depth header on a LOCK refresh.
>
>
> Section 9.10.2., para. 2:
> OLD:
>
>     If the resource has other (shared) locks, those locks are  
> unaffected
>     by a lock refresh.  Additionally, those locks do not prevent the
>     named lock from being refreshed.
>
> NEW:
>
>     If the resource has other (shared) locks, those locks are  
> unaffected
>     by a lock refresh.  Additionally, those locks do not prevent the
>     named locks from being refreshed.
>
>
> Section 9.10.2., para. 3:
> OLD:
>
>     Note that in [RFC2518], clients were indicated through the  
> example in
>     the text to use the If header to specify what lock to refresh  
> (rather
>     than the Lock-Token header).  Servers are encouraged to  
> continue to
>     support this as well as the Lock-Token header.
>
>     Note that the Lock-Token header is not returned in the response  
> for a
>     successful refresh LOCK request, but the LOCK response body MUST
>     contain the new value for the DAV:lockdiscovery body.
>
> NEW:
>
>     The response body MUST contain a DAV:lockdiscovery property with
>     'activelock' child elements indicating the current status of each
>     lock that was refreshed.
>
>
> Section 9.10.6., para. 6:
> OLD:
>
>     409 (Conflict), with 'lock-token-matches-request-uri' precondition
>     code - The LOCK request was made with a Lock-Token header,  
> indicating
>     that the client wishes to refresh the given lock.  However, the
>     Request-URI did not fall within the scope of the lock  
> identified by
>     the token.  The lock may have a scope that does not include the
>     Request-URI, or the lock could have disappeared, or the token  
> may be
>     invalid.
>
> NEW:
>
>     412 (Precondition Failed), with 'lock-token-submitted'  
> precondition
>     code - The LOCK request was made with an If header, indicating  
> that
>     the client wishes to refresh the given lock.  However, the  
> Request-
>     URI did not fall within the scope of the lock identified by the
>     token.  The lock may have a scope that does not include the  
> Request-
>     URI, or the lock could have disappeared, or the token may be  
> invalid.
>
>
> Section 9.10.8., para. 2:
> OLD:
>
>       LOCK /workspace/webdav/proposal.doc HTTP/1.1
>       Host: example.com
>       Timeout: Infinite, Second-4100000000
>       Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
>       Authorization: Digest username="ejw",
>         realm="ejw <at> example.com", nonce="...",
>         uri="/workspace/webdav/proposal.doc",
>         response="...", opaque="..."
>
> NEW:
>
>       LOCK /workspace/webdav/proposal.doc HTTP/1.1
>       Host: example.com
>       Timeout: Infinite, Second-4100000000
>       If: (<urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
>       Authorization: Digest username="ejw",
>         realm="ejw <at> example.com", nonce="...",
>         uri="/workspace/webdav/proposal.doc",
>         response="...", opaque="..."
>
>
> Section 16., para. 14:
> OLD:
>
>     Purpose: (precondition) -- A request may include a Lock-Token  
> header
>        to identify a lock for the purposes of an operation such as
>        refresh LOCK or UNLOCK.  However, if the Request-URI does  
> not fall
>        within the scope of the lock identified by the token, the  
> server
>        SHOULD use this error.  The lock may have a scope that does not
>        include the Request-URI, or the lock could have disappeared, or
>        the token may be invalid.
>
> NEW:
>
>     Purpose: (precondition) -- A request may include a Lock-Token  
> header
>        to identify a lock for the purposeof UNLOCK.  However, if the
>        Request-URI does not fall within the scope of the lock  
> identified
>        by the token, the server SHOULD use this error.  The lock  
> may have
>        a scope that does not include the Request-URI, or the lock  
> could
>        have disappeared, or the token may be invalid.
>
>
> Appendix E., para. 14:
> OLD:
>
>     o  There is no implicit refresh of locks anymore.  Locks are only
>        refreshed upon explicit request.  Furthermore, the lock  
> token for
>        the lock to be refreshed is now specified in the Lock-Token
>        request header rather than the If header (see Section 9.10.2).
>
> NEW:
>
>     o  There is no implicit refresh of locks anymore.  Locks are only
>        refreshed upon explicit request (see Section 9.10.2).
>
>
> Best regards, Julian