Re: WebDAV PUSH based on RFC 6202

[Ken Murchison <[e-mail]>]

I wasn't aware of this draft.  Do you feel that this approach is 
superior, and if so, would be consider resurrecting the draft?


On 04/09/2014 12:36 PM, Peter Saint-Andre wrote:
> <troll>
> http://tools.ietf.org/id/draft-hildebrand-webdav-notify-00.txt
> </troll>
>
> On 4/9/14, 9:28 AM, Ken Murchison wrote:
>> 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 <http://datatracker.ietf.org/doc/rfc6578/>
>> and HTTP long-polling <http://datatracker.ietf.org/doc/rfc6202/>.  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
>> <http://tools.ietf.org/html/draft-snell-http-prefer> 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
>>
>


-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University