- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Tue, 22 Jul 2014 10:23:48 -0500
- To: Cyrus Daboo <cyrus@daboo.name>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jul 22, 2014 at 9:33 AM, Cyrus Daboo <cyrus@daboo.name> wrote: > Hi, > I wanted to weigh in on one specific use case for 1xx that has come up in > CalDAV (RFC4791 - a WebDAV based calendaring and scheduling protocol). > > Some CalDAV PUT/POST requests might take a long time to process (of the > order of several minutes or more). Typically clients (in particular mobile > clients) implement a client-side response timeout (often 2 minutes or so). > If we know the request is likely to succeed obviously we want to keep the > client connection alive past their timeout so that the response gets > through. The original WebDAV spec (RFC2518) defined the 102 code for that > purpose, but that code was removed (not deprecated) in the WebDAV update > (RFC4918) because it was not being used. > > Well now, some CalDAV servers are using 100-Continue as a keep-alive That seems a misuse of 100. Maybe 303 (one or more) is better. > mechanism, and there are a couple of tweaks to that that would be handy > (e.g., making use of a Prefer header that allows the client to communicate > to the server what its client-side timeout is). Perhaps we should have > adopted 102 for this purpose, but 100 seems to work well. > > Some CalDAV implementations also make use of the "Expect: 100-continue" > mechanism for handling uploads of large event attachments that servers often > redirect from the "base URI" for attachment uploads. > > So as far as HTTP/1.1 goes 100 (and possibly 102) are important for CalDAV. > In terms of HTTP/2, I presume the PING frame can be used for "keep-alive". > But I definitely want to see the equivalent of "Expect: 100-continue" > available in some fashion (either the same as HTTP/1.1 or via some new > feature specific to HTTP/2). > > -- > Cyrus Daboo > >
Received on Tuesday, 22 July 2014 15:24:16 UTC