- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 22 Jul 2014 16:46:53 +0200
- To: Cyrus Daboo <cyrus@daboo.name>, HTTP Working Group <ietf-http-wg@w3.org>
On 2014-07-22 16:33, Cyrus Daboo 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. I'd rephrase this as: it wasn't included in 4918 because we had zero implementations (mainly because most WebDAV servers people worked on back then were running on the Java servlet API, which didn't provide a way to send non-final responses). That means it continues to be defined in 2518 (as "proposed standard"). > 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. I'd say that using 100 for this is sort-of ok (it if serves the purpose), but it would be good to understand how the implementers that chose 100 over 102 came to the conclusion that it's better. It seems we have a education problem here; what's relevant for the applicability of status codes is how it appears in the IANA registry, after all. > 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). Best regards, Julian
Received on Tuesday, 22 July 2014 14:47:28 UTC