Re: [tc-push-l] WebDAV PUSH based on RFC 6202
Marten Gajda <marten@dmfs.org> Sat, 19 April 2014 09:52 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 CA5CE1A00D8 for <ietfarch-webdav-archive@ietfa.amsl.com>; Sat, 19 Apr 2014 02:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.274
X-Spam-Level:
X-Spam-Status: No, score=-5.274 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 nX5OYqtge8GG for <ietfarch-webdav-archive@ietfa.amsl.com>; Sat, 19 Apr 2014 02:52:47 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id A7AB71A00CD for <webdav-archive@lists.ietf.org>; Sat, 19 Apr 2014 02:52:47 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <w3c-dist-auth-request@listhub.w3.org>) id 1WbRuo-0007y3-2E for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Apr 2014 09:50:30 +0000
Resent-Date: Sat, 19 Apr 2014 09:50:30 +0000
Resent-Message-Id: <E1WbRuo-0007y3-2E@frink.w3.org>
Received: from jessica.w3.org ([128.30.52.49]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <marten.gajda@googlemail.com>) id 1WbRun-0007wi-B8 for w3c-dist-auth@listhub.w3.org; Sat, 19 Apr 2014 09:50:29 +0000
Received: from www-data by jessica.w3.org with local (Exim 4.72) (envelope-from <marten.gajda@googlemail.com>) id 1WbRun-0003rX-87 for w3c-dist-auth@listhub.w3.org; Sat, 19 Apr 2014 09:50:29 +0000
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <marten.gajda@googlemail.com>) id 1WbGtv-0006Fb-5z for w3c-dist-auth@listhub.w3.org; Fri, 18 Apr 2014 22:04:51 +0000
Received: from mail-ee0-f47.google.com ([74.125.83.47]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <marten.gajda@googlemail.com>) id 1WbGts-0002yM-MY for w3c-dist-auth@w3.org; Fri, 18 Apr 2014 22:04:51 +0000
Received: by mail-ee0-f47.google.com with SMTP id b15so1966104eek.34 for <w3c-dist-auth@w3.org>; Fri, 18 Apr 2014 15:04:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=KpiDKZvqKmXIABDkMEP+bbmRVTTytFcBwUDdp98hw5g=; b=rowjrE43fBwgPNtOLsVMwqoEvdj7Fl9BiryekmTaRoSFCpoNEVzY3+NN73JYEevhT5 KfaHuv+AoVUnecFVlosnRz+8OQL6m+ufFfmf+g2/qeYhwJeBstJ0ruJCqt87pf0Pj/WJ SGWhmXGUPI/4AFD1SfLJtQDnKOl1otsWQx+yKFJYxYRtvwMuOsrbjO7tICm55vhcSlO8 LielfaxtHx72qpFe/qx5fzuz37bdw6EMZofRXagA/et5x0HT6RcduTPYoDc9GR7p8jYx Pn+GC+NlG+2D4TswGpWuVet7FVr10HBOyeVPJhC4gbu7H5I8ykq99L0E4zNch7buCJ+x 84Tg==
X-Received: by 10.15.98.68 with SMTP id bi44mr4309380eeb.97.1397858661816; Fri, 18 Apr 2014 15:04:21 -0700 (PDT)
Received: from smtp.dmfs.org (pD9EA6D27.dip0.t-ipconnect.de. [217.234.109.39]) by mx.google.com with ESMTPSA id 48sm80146529eee.2.2014.04.18.15.04.19 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 18 Apr 2014 15:04:20 -0700 (PDT)
Sender: Marten Gajda <marten.gajda@googlemail.com>
Received: from [127.0.0.1] (mephisto.fritz.box [192.168.2.18]) by smtp.dmfs.org (Postfix) with ESMTPSA id C8D197E3; Sat, 19 Apr 2014 00:04:17 +0200 (CEST)
Message-ID: <5351A15F.5080101@dmfs.org>
Date: Sat, 19 Apr 2014 00:04:15 +0200
From: Marten Gajda <marten@dmfs.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
CC: tc-push-l@lists.calconnect.org
References: <53457537.8040205@andrew.cmu.edu> <534E923A.6020404@wisc.edu>
In-Reply-To: <534E923A.6020404@wisc.edu>
Content-Type: multipart/alternative; boundary="------------040500050603070109070003"
Received-SPF: pass client-ip=74.125.83.47; envelope-from=marten.gajda@googlemail.com; helo=mail-ee0-f47.google.com
X-W3C-Hub-Spam-Status: No, score=-0.7
X-W3C-Hub-Spam-Report: DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1WbGts-0002yM-MY 769a8bbf3819ae5fe0d393395bbeae2f
X-caa-id: 35cd94a744
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: [tc-push-l] WebDAV PUSH based on RFC 6202
Archived-At: <http://www.w3.org/mid/5351A15F.5080101@dmfs.org>
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/13425
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>
Hi all, today, "AwareDAV" has been brought to my attention, see http://www2005.org/docs/p180.pdf Does anyone have any experience with it? cheers Marten Am 16.04.2014 16:22, schrieb Jesse Thompson: > I chimed in on this conversation on thetc-push-l@lists.calconnect.org > list. Cyrus asked me to post my comments here. (I tried to refactor > content from multiple messages for context, but I apologize if it is > still a bit jumbled - and for top posting) > > I don't have much knowledge in implementing push/realtime HTTP other > than installing various web clients on top of Ejabberd using XEP-0206 > (XMPP over BOSH) and deciding not to use XEP-0025 (Jabber XMPP Polling > at UW-Madison. > http://xmpp.org/extensions/xep-0206.html > http://xmpp.org/extensions/xep-0025.html > > Otherwise, what I am saying is based on what I have read or what others > have told me, so take it with a grain of salt. > > I suggested looking at the work being done on websockets for XMPP. Not > that XMPP should be used as the protocol, but rather that they might > have documented some of the same hurdles you are trying to overcome. > http://tools.ietf.org/html/draft-ietf-xmpp-websocket-02 > > From my standpoint as a calendar server administrator, I shudder to > think of the impact of having tens of thousands of clients keeping > connections open to my main Apache preforking servers. The root of my > recommendation is not to say whether long polling is better or worse > than web sockets, but rather to suggest the option to have the clients > make these long running requests to a secondary URI. This would allow > server administrators to handle those request with a web server > specifically optimized for that type of connection. > > In response to Brad, who brought up the topic of what data is sent over > the websocket, I said that I would consider it an implementation detail > as to what information (and how much) to send over the web socket > connection vs. telling the client to sync via the normal connection. > > The people I know who have implemented realtime web apps generally ditch > the idea of long polling because it doesn't scale. They use web > sockets, but they have clients connect on a different connection than > the main web server that is serving normal requests. > > Not all web servers are non-blocking/asynchronous, so you might not be > able/willing to completely replace existing web servers and downstream > reverse proxy servers. The 2-web server strategy allows you to add in > push capabilities while remaining backwards compatible, as well as > segregate load. If your web sockets server becomes overloaded, clients > should be able to fall back on the non-push capabilities. > > For an example, I know the guys that built > https://www.thegamecrafter.com/ Their main web servers are not handling > any of the web sockets connections. But their application is still > capable of pushing real time updates. They accomplish this by having > the client (javascript) maintain a connection to > https://www.firebase.com/ to receive those updates. > > Firebase is an example of a cloud hosting service for realtime apps. It > allows you to outsource the realtime/push capabilities of your apps. I > don't know if something like that would be appropriate for calendaring, > but it might be an instructive exercise to proof-of-concept leveraging > this type of solution for your work on tc-push. It might at least lead > you to the answers to the questions your were asking. > > Anyway, I hope this is helpful information. > > -- > Jesse Thompson > Technical Consultant - Messaging > Productivity and Collaboration Solutions > Division of Information Technology > University of Wisconsin–Madison > > On 4/9/2014 11: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 >> >> >> >> _______________________________________________ >> tc-push-l mailing list >> tc-push-l@lists.calconnect.org >> http://lists.calconnect.org/mailman/listinfo/tc-push-l >> > _______________________________________________ > tc-push-l mailing list > tc-push-l@lists.calconnect.org > http://lists.calconnect.org/mailman/listinfo/tc-push-l -- *Marten Gajda* Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten@dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391
- 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