W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Getting to Consensus on 1xx Status Codes (#535)

From: Cyrus Daboo <cyrus@daboo.name>
Date: Tue, 22 Jul 2014 10:33:31 -0400
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <10E79DF776ACC559932F06CE@caldav.corp.apple.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC