Re: WebDAV PUSH based on RFC 6202
Peter Saint-Andre <stpeter@stpeter.im> Wed, 09 April 2014 16:38 UTC
Return-Path: <w3c-dist-auth-request@listhub.w3.org>
X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com
Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B731A03DC for <ietfarch-webdav-archive@ietfa.amsl.com>; Wed, 9 Apr 2014 09:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.174
X-Spam-Level:
X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J48DeUG6zVIF for <ietfarch-webdav-archive@ietfa.amsl.com>; Wed, 9 Apr 2014 09:38:04 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 75F1F1A0380 for <webdav-archive@lists.ietf.org>; Wed, 9 Apr 2014 09:38:04 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <w3c-dist-auth-request@listhub.w3.org>) id 1WXvUv-0004lv-4U for w3c-dist-auth-dist@listhub.w3.org; Wed, 09 Apr 2014 16:37:13 +0000
Resent-Date: Wed, 09 Apr 2014 16:37:13 +0000
Resent-Message-Id: <E1WXvUv-0004lv-4U@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <stpeter@stpeter.im>) id 1WXvUu-0004lH-4C for w3c-dist-auth@listhub.w3.org; Wed, 09 Apr 2014 16:37:12 +0000
Received: from mailhost.stpeter.im ([207.210.219.225] helo=stpeter.im) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <stpeter@stpeter.im>) id 1WXvUo-0000Qr-Jn for w3c-dist-auth@w3.org; Wed, 09 Apr 2014 16:37:12 +0000
Received: from aither.local (unknown [66.191.14.77]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4E34B40352; Wed, 9 Apr 2014 10:36:45 -0600 (MDT)
Message-ID: <5345771C.9090909@stpeter.im>
Date: Wed, 09 Apr 2014 09:36:44 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Ken Murchison <murch@andrew.cmu.edu>, WebDAV <w3c-dist-auth@w3.org>
References: <53457537.8040205@andrew.cmu.edu>
In-Reply-To: <53457537.8040205@andrew.cmu.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=207.210.219.225; envelope-from=stpeter@stpeter.im; helo=stpeter.im
X-W3C-Hub-Spam-Status: No, score=-0.3
X-W3C-Hub-Spam-Report: RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1WXvUo-0000Qr-Jn ce61dafd91d797d7911bd6e7e3f04024
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: WebDAV PUSH based on RFC 6202
Archived-At: <http://www.w3.org/mid/5345771C.9090909@stpeter.im>
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/13419
X-Loop: w3c-dist-auth@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:w3c-dist-auth@w3.org>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
<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 >
- Re: [tc-push-l] WebDAV PUSH based on RFC 6202 Jesse Thompson
- WebDAV PUSH based on RFC 6202 Ken Murchison
- Re: WebDAV PUSH based on RFC 6202 Peter Saint-Andre
- Re: WebDAV PUSH based on RFC 6202 Ken Murchison
- Re: WebDAV PUSH based on RFC 6202 Peter Saint-Andre
- Re: WebDAV PUSH based on RFC 6202 Cyrus Daboo
- Re: [tc-push-l] WebDAV PUSH based on RFC 6202 Marten Gajda