- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Tue, 22 Jul 2014 11:24:56 -0500
- To: Cyrus Daboo <cyrus@daboo.name>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jul 22, 2014 at 10:32 AM, Cyrus Daboo <cyrus@daboo.name> wrote: > Hi Zhong, > > > --On July 22, 2014 at 10:23:48 AM -0500 Zhong Yu <zhong.j.yu@gmail.com> > wrote: > >>> 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. > > > I don't see how that can be applicable to this keep-alive case. If we wanted > to have the client do a follow-up request to get the actual result of a time > consuming request, then 202 Accepted would be the better way to do that. There's no official way for a 202 response to indicate where to send a follow-up request. My idea of using 303 for keep-alive is as the following: The client posts a task, the server immediately responds with HTTP/1.1 303 See Other Location: /result?id=1234&timeout=60&try=1 which triggers the client to send a GET request to retrieve the result. For this request, the server blocks until either the result is available, in which case it returns the final response, or the timeout is reached, in which case it responds with another 303 HTTP/1.1 303 See Other Location: /result?id=1234&timeout=60&try=2 and so on. The semantics is sanctioned by the spec. The behavior is directed by the server, requiring no change in app protocol or client software (assuming it handles 303s transparently). Zhong Yu bayou.io > > -- > Cyrus Daboo >
Received on Tuesday, 22 July 2014 16:25:25 UTC