Ken Murchison | 16 Dec 15:42 2014
Picon

draft-murchison-webdav-prefer

All,

I'd like to get some feedback on draft-murchison-webdav-prefer .  This work came out of discussions in CalConnect and is mostly geared towards the needs of CalDAV/CardDAV clients, but might also be useful for generic WebDAV.  There are several server implementations and support is starting to trickle into clients, including the Apple clients.

Happy Holidays!
Ken
-- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
Ken Murchison | 9 Apr 18:28 2014
Picon

WebDAV PUSH based on RFC 6202

All,

The Calendaring and Scheduling Consortium (CalConnect) is looking at ways to have a server "push" changes made to a calendar/addressbook collection out to a client.  There are already a few proprietary mechanisms in place for doing so, but we would like to come up with something standard that would be relatively simple to implement for both clients and servers and would be applicable to any DAV collection.

One idea that we are toying with is to leverage the existing DAV:sync-collection REPORT and HTTP long-polling.  I spent a few hours coding up a prototype version of HTTP long-polling and HTTP streaming for DAV:sync-collection REPORTs in my server which I describe below.  We (CalConnect) are considering using this approach or something similar as a starting point and we are interested in any/all feedback from the larger DAV community, including:
  • Is this approach sane, is there a better way, or is any type of push via HTTP a hopeless endeavor?
  • Will this approach (or anything similar) break in the face of intermediaries?
  • Will existing HTTP/DAV stacks be able to handle long-polling and/or streaming?
  • Should the server advertise its ability to long-poll and/or stream for the client to discover or simply leave it up to the client try one or both and see what the server does, as is the case in my implementation below?

Long-polling:

For long-polling, I leveraged the HTTP Prefer header and its 'wait' preference as a way for the client to tell the server that it wants to long poll.  If the client doesn't specify a DAV:sync-token (initial sync) or if there have been changes since the specified token, then the server will respond immediately.  Otherwise, it will only respond if a change is detected or when the timeout expires, whichever comes first.  In the case of a delayed response, I issue a 100 (Continue) provisional response with a Preference-Applied header to notify the client that the server is indeed long-polling as requested.  This provisional response may or may not be necessary.  In my implementation I wait 1 sec less than specified to account for processing time so I don't go over what the client expects.

Streaming:

The client can request streaming behavior by simply including an Accept header with the 'multipart/mixed' media type (I chose this subtype for lack of something better - we could use the existing x-mixed-replace or create our own).  The client can also specify a timeout for the streaming using the same 'wait' preference as used for long-polling.  In the absence of a client-requested timeout, the server will continue to add body parts until the client disconnects or the server hits some internal timeout.  Because a multipart response allows for an epilogue following the final delimiter, a client can't just rely on the delimiters to detect the end of the response.  Therefore, the server MUST use either chunked TE or close the connection following the multipart response.  In my example below, I close-delimit the response for better readability.  FWIW, I think the same holds true for multipart/byteranges responses.  In my implementation I include a Content-Length header in the body-part headers so the client can detect the end of the XML body without looking for the trailing delimiter (mainly because the trailing delimiter doesn't appear until the next body part).

Examples:

Here is an example of long-polling with 3 requests (I added superfluous Date headers to show the timing).  The first request returns immediately due to a pre-existing change, the second returns upon detecting a subsequent change some 95 sec later, and the third times out after 3 min.

REPORT /dav/calendars/user/ken/Default/ HTTP/1.1
Host: localhost
Date: Wed, 30 Oct 2013 18:11:11 GMT
Content-Type: application/xml
Content-Length: 260
Prefer: return=minimal, wait=180

<?xml version="1.0" encoding="UTF-8"?>
<C:sync-collection xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-354</D:sync-token>
  <D:sync-level>1</D:sync-level>
  <D:prop/>
</C:sync-collection>

HTTP/1.1 207 Multi-Status
Date: Wed, 30 Oct 2013 18:11:11 GMT
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal, wait=180
Content-Type: application/xml; charset=utf-8
Content-Length: 421

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>/dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics</D:href>
    <D:propstat>
      <D:prop/>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-355</D:sync-token>
</D:multistatus>



REPORT /dav/calendars/user/ken/Default/ HTTP/1.1
Host: localhost
Date: Wed, 30 Oct 2013 18:11:12 GMT
Content-Type: application/xml
Content-Length: 260
Prefer: return=minimal, wait=180

<?xml version="1.0" encoding="UTF-8"?>
<C:sync-collection xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-355</D:sync-token>
  <D:sync-level>1</D:sync-level>
  <D:prop/>
</C:sync-collection>

HTTP/1.1 100 Continue
Date: Wed, 30 Oct 2013 18:11:12 GMT
Preference-Applied: wait=180

HTTP/1.1 207 Multi-Status
Date: Wed, 30 Oct 2013 18:12:47 GMT
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal, wait=180
Content-Type: application/xml; charset=utf-8
Content-Length: 375

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>/dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics</D:href>
    <D:status>HTTP/1.1 404 Not Found</D:status>
  </D:response>
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
</D:multistatus>



REPORT /dav/calendars/user/ken/Default/ HTTP/1.1
Host: localhost
Date: Wed, 30 Oct 2013 18:12:48 GMT
Content-Type: application/xml
Content-Length: 260
Prefer: return=minimal, wait=180

<?xml version="1.0" encoding="UTF-8"?>
<C:sync-collection xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
  <D:sync-level>1</D:sync-level>
  <D:prop/>
</C:sync-collection>

HTTP/1.1 100 Continue
Date: Wed, 30 Oct 2013 18:12:48 GMT
Preference-Applied: wait=180

HTTP/1.1 207 Multi-Status
Date: Wed, 30 Oct 2013 18:15:47 GMT
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal, wait=180
Content-Type: application/xml; charset=utf-8
Content-Length: 202

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
</D:multistatus>



Here is the same sequence of events utilizing streaming with a timeout:

REPORT /dav/calendars/user/ken/Default/ HTTP/1.1
Host: localhost
Date: Wed, 30 Oct 2013 18:11:06 GMT
Content-Type: application/xml
Content-Length: 260
Prefer: return=minimal, wait=180
Accept: multipart/mixed

<?xml version="1.0" encoding="UTF-8"?>
<C:sync-collection xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-354</D:sync-token>
  <D:sync-level>1</D:sync-level>
  <D:prop/>
</C:sync-collection>

HTTP/1.1 207 Multi-Status
Connection: close
Date: Wed, 30 Oct 2013 18:11:06 GMT
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal, wait=180
Content-Type: multipart/mixed; boundary="localhost-29378-1383156666-1025603243"

This is a message with multiple parts in MIME format.

--localhost-29378-1383156666-1025603243
Date: Wed, 30 Oct 2013 18:11:06 GMT
Content-Type: application/xml; charset=utf-8
Content-Length: 421

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>/dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics</D:href>
    <D:propstat>
      <D:prop/>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-355</D:sync-token>
</D:multistatus>

--localhost-29378-1383156666-1025603243
Date: Wed, 30 Oct 2013 18:12:47 GMT
Content-Type: application/xml; charset=utf-8
Content-Length: 375

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>/dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics</D:href>
    <D:status>HTTP/1.1 404 Not Found</D:status>
  </D:response>
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
</D:multistatus>

--localhost-29378-1383156666-1025603243
Date: Wed, 30 Oct 2013 18:14:05 GMT
Content-Type: application/xml; charset=utf-8
Content-Length: 202

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
</D:multistatus>

--localhost-29378-1383156666-1025603243--

End of MIME multipart body.

-- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
Julian Reschke | 11 Dec 11:13 2013
Picon
Picon

unsubscribing

Instructions are here: http://lists.w3.org/Archives/Public/w3c-dist-auth/

Jim Schatzman | 10 Dec 04:03 2013

WebDAV Bug?

Can anyone explain the following behavior and how to fix it?

I am running WebDAV with Apache2 version 2.2.15. 

I take a tgz file and split it. The files are named

test_xaa  test_xab test_xac etc.

I then attempt to download the files through a browser. I have tried several browsers and the result is
always the same.

test_xab, test_xac, etc download without difficulty.

However test_xaa gets renamed "test_xaa.tar" and it is, in fact unzipped, sort of. This a problem because
it is invalid, since it was not unzipped with the other files attached. It cannot be just re-zipped and then
the collection of files unsplit and unzipped, because zipping does not reproduce the original file.
There does not seem to be any way to recover.

Equally oddly, if I rename test_xaa to test_xaa.tgz, then it downloads without difficulty. It is not
renamed, and it is not unzipped.

I can find no reference to this behavior in online WebDAV manuals.

Thanks!

Jim

Ken Murchison | 3 Jan 21:59 2013
Picon

LOCKing an unmapped URL

If a write lock is successfully created on an unmapped URL, should an 
ETag (with associated Location header) be returned for the empty 
resource in the 201 response?

--

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

Ken Murchison | 23 Dec 22:00 2012
Picon

If header field and conditional precedence

Happy Holidays to All!

I'm trying to figure out where the If header field fits in the 
precedence order outlined in:
http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-21#section-5

I assume that the If header field should be evaluated in a step 0, but 
my question is what should happen when the If header is present and 
evaluates to true?  Should processing continue to step 3 or step 1?  In 
other words, does If completely supersede If-Match, where a client 
wishing to submit both a state token and an ETag MUST only use If, or is 
a client allowed to submit a state token with If AND submit an ETag with 
If-Match?

In text, the two options might look something like this:

    0.  When If is present, evaluate it:

        *  if true, continue to step 3

        *  if false, respond 412 (Precondition Failed)

    1.  When If is not present and If-Match is present,
        evaluate it:

    ...

OR

    0.  When If is present, evaluate it:

        *  if true, continue to step 1

        *  if false, respond 412 (Precondition Failed)

    1.  When If-Match is present, evaluate it:

    ...

--

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

Federico Di Gregorio | 29 Aug 12:29 2012
Picon

Ambiguous example for COPY in RFC 4918

Dear all,

this is my first post to this list so, if this is not the correct
mailing list to discuss the topic, please, just tell me and I'll forward
it to a more appropriate forum.

We're working at a C# implementation of RFC 4918 and while most parts of
it are quite clear we found one example that, if taken with the text
preceding it, is quite puzzling. About a COPY operation with infinite
Depth and Overwrite:T the RFC says:

    9.8.4 COPY and Overwriting Destination Resources

    [...]
    When a collection is overwritten, the membership of the destination
    collection after the successful COPY request must be the same
    membership as the source collection immediately before the COPY.
    Thus, merging the membership of the source and destination
    collections together in the destination is not a compliant behavior.
    [...]

But the example "9.8.8 Example - COPY of a Collection" says that
"[...]Because there was an error copying R2, none of R2's members were
copied.[...]". Our understanding is that in the destination tree
/othercontainer/R2/ is still the member from the original
/othercontainer/ collection while R2 siblings in the source collection
/container/ have been copied correctly.

E.g., if we're asked to COPY

/container/
/container/R1
/container/R2/
/container/R2/A

into

/othercontainer/
/othercontainer/R2/
/othercontainer/R2/X

and R2 is locked, the final layout is:

/othercontainer/R1
/othercontainer/R2/
/othercontainer/R2/X

Isn't this the opposite of the behaviour specified in 9.8.4? Did we
interpret the example the wrong way? What is the supposed behaviour if
the resources are as in the example above?

Thank you very much fir your time,

federico

--

-- 
Federico Di Gregorio                         federico.digregorio <at> dndg.it
Studio Associato Di Nunzio e Di Gregorio                  http://dndg.it
           Purtroppo i creazionisti non si sono ancora estinti. -- vodka

Julian Reschke | 2 Jun 11:38 2012
Picon
Picon

Microsoft Mini-Redirector Bug with respect to handling DAV:href

Hi there,

reporting here so it get's archived:

Version: Microsoft-WebDAV-MiniRedir/6.1.7601

Problem: client is doing a PROPFIND request without payload, thus 
defaulting to DAV:allprop.

Server returns a custom property than *contains* a DAV:href child 
element, like that:

<D:response>
   <D:href>/foo/bar.txt</D:href>
   <D:propstat>
     <D:prop>
       <D:displayname>bar.txt</D:displayname>
       <D:creationdate>2012-06-01T12:52:57Z</D:creationdate>
       <D:resourcetype/>
       <D:lockdiscovery/>
       <D:getcontenttype>text/plain; charset=UTF-8</D:getcontenttype>
       <C:linked-from xmlns:C="http://example.com/ns">
         <D:href>/qux</D:href>
       </C:linked-from>
       <D:getetag>"7248-1338555179558"</D:getetag>
       <D:getlastmodified>Fri, 01 Jun 2012 12:52:59 GMT</D:getlastmodified>
       <D:supportedlock>
         <D:lockentry>
           <D:lockscope><D:exclusive/></D:lockscope>
           <D:locktype><D:write/></D:locktype>
         </D:lockentry>
       </D:supportedlock>
       <D:getcontentlength>7248</D:getcontentlength>
     </D:prop>
     <D:status>HTTP/1.1 200 OK</D:status>
   </D:propstat>
</D:response>

So the response element contains a top-level DAV:href for the URI for of 
the resource:

   <D:href>/foo/bar.txt</D:href>

...but also a nested...

       <C:linked-from xmlns:C="http://example.com/ns">
         <D:href>/qux</D:href>
       </C:linked-from>

inside D:propstat/D:prop.

The client apparently gets confused and uses the second DAV:href 
element; causing a wrong name to be displayed (and likely the wrong 
resource to be used when opened).

Best regards, Julian

Syl-J CALIMPUSAN | 10 Feb 18:12 2012
Picon

Re: webDAV apple open source

Yes, where can I get the header file NetFSPrivate.h?





On Fri, Feb 10, 2012 at 1:02 AM, <gonzdavid76 <at> aol.com> wrote:
Excuse me? Is that a question?

I am having a hard time compiling the webDAV apple open source codes.  I am missing NetFS/NetFSPrivate.h header files.  Anyone has access to that file?

Thanks.

Syl-J CALIMPUSAN | 9 Feb 02:40 2012
Picon

webDAV apple open source

I am having a hard time compiling the webDAV apple open source codes.  I am missing NetFS/NetFSPrivate.h header files.  Anyone has access to that file?


Thanks.
Cyrus Daboo | 19 Jan 17:21 2012

New Version Notification for draft-daboo-webdav-sync-07.txt (fwd)

Hi folks,
FYI We have posted a new -07 version of the sync report draft that 
addresses the last call, IESG review etc comments. Please take a look at 
the changes and make sure these are OK.

------------ Forwarded Message -----------
Date: January 19, 2012 8:18:19 AM -0800
From: internet-drafts <at> ietf.org
To: cyrus <at> daboo.name
cc: cyrus <at> daboo.name, arnaud.quillaud <at> oracle.com
Subject: New Version Notification for draft-daboo-webdav-sync-07.txt

A new version of I-D, draft-daboo-webdav-sync-07.txt has been successfully
submitted by Cyrus Daboo and posted to the IETF repository.

Filename:	 draft-daboo-webdav-sync
Revision:	 07
Title:		 Collection Synchronization for WebDAV
Creation date:	 2012-01-19
WG ID:		 Individual Submission
Number of pages: 32

Abstract:
   This specification defines an extension to Web Distributed Authoring
   and Versioning (WebDAV) that allows efficient synchronization of the
   contents of a WebDAV collection.

Editorial Note (To be removed by RFC Editor before publication)

   Please send comments to the Distributed Authoring and Versioning
   (WebDAV) working group at &lt;mailto:w3c-dist-auth <at> w3.org&gt;, which may
be    joined by sending a message with subject &quot;subscribe&quot; to
&lt;mailto:w3c-dist-auth-request <at> w3.org&gt;.  Discussions of the WEBDAV
working group are archived at
   &lt;http://lists.w3.org/Archives/Public/w3c-dist-auth/&gt;.

The IETF Secretariat

---------- End Forwarded Message ----------

--

-- 
Cyrus Daboo


Gmane