WebDAV PUSH based on RFC 6202
Ken Murchison <murch@andrew.cmu.edu> Wed, 09 April 2014 16:31 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 7040B1A0380 for <ietfarch-webdav-archive@ietfa.amsl.com>; Wed, 9 Apr 2014 09:31:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.473
X-Spam-Level:
X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 22sFQFvmgi3f for <ietfarch-webdav-archive@ietfa.amsl.com>; Wed, 9 Apr 2014 09:31:12 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 251C91A032E for <webdav-archive@lists.ietf.org>; Wed, 9 Apr 2014 09:31:11 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <w3c-dist-auth-request@listhub.w3.org>) id 1WXvN8-0002Ng-DM for w3c-dist-auth-dist@listhub.w3.org; Wed, 09 Apr 2014 16:29:10 +0000
Resent-Date: Wed, 09 Apr 2014 16:29:10 +0000
Resent-Message-Id: <E1WXvN8-0002Ng-DM@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <murch@andrew.cmu.edu>) id 1WXvN7-0002My-VC for w3c-dist-auth@listhub.w3.org; Wed, 09 Apr 2014 16:29:10 +0000
Received: from smtp.andrew.cmu.edu ([128.2.157.37]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <murch@andrew.cmu.edu>) id 1WXvN5-0005lr-CP for w3c-dist-auth@w3.org; Wed, 09 Apr 2014 16:29:09 +0000
Received: from localhost.localdomain (cpe-76-180-197-142.buffalo.res.rr.com [76.180.197.142]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.7/8.14.8) with ESMTP id s39GSdfk009135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Apr 2014 12:28:39 -0400
Message-ID: <53457537.8040205@andrew.cmu.edu>
Date: Wed, 09 Apr 2014 12:28:39 -0400
From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: WebDAV <w3c-dist-auth@w3.org>
Content-Type: multipart/alternative; boundary="------------070102000200060809090905"
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.9.161819
X-SMTP-Spam-Clean: 27% ( SXL_IP_DYNAMIC 3, BODY_SIZE_10000_PLUS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __BAT_BOUNDARY 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __FW_1LN_BOT_MSGID 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0)
X-SMTP-Spam-Score: 27%
X-Scanned-By: MIMEDefang 2.74 on 128.2.157.37
Received-SPF: none client-ip=128.2.157.37; envelope-from=murch@andrew.cmu.edu; helo=smtp.andrew.cmu.edu
X-W3C-Hub-Spam-Status: No, score=-3.6
X-W3C-Hub-Spam-Report: AWL=-3.315, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272
X-W3C-Scan-Sig: maggie.w3.org 1WXvN5-0005lr-CP 9dc43861d199acf388cb524f528b99f5
X-Original-To: w3c-dist-auth@w3.org
Subject: WebDAV PUSH based on RFC 6202
Archived-At: <http://www.w3.org/mid/53457537.8040205@andrew.cmu.edu>
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/13418
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>
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