- From: Cyrus Daboo <cyrus@daboo.name>
- Date: Tue, 22 Jul 2014 10:33:31 -0400
- To: HTTP Working Group <ietf-http-wg@w3.org>
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 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 14:33:57 UTC