W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

Revisiting Retry-After w/ 202

From: mike amundsen <mamund@yahoo.com>
Date: Thu, 3 Jun 2010 01:53:42 -0400
Message-ID: <AANLkTikJ0AvKu5DA9BNANoqtXayR8dFd1y96CVoktU-A@mail.gmail.com>
To: ietf-http-wg@w3.org
I know this has come up on this list in the past[1] but I was unable to find any
clear resolution in the archives.

I have cases where the server will queue up the client's request
(POST/PUT/DELETE) and/or start a long-running task. I some cases I
need the response to indicate to clients that they can check the
status/results of the processing within a certain interval (ala HTML
"meta refresh").

I know that 202 responses SHOULD contain indications of status, a
monitor location and/or time estimates. However I want to  indicate
the same data w/o requiring bots to "find" the information w/in the
message body; a media-type agnostic solution.

As a temporary solution, when returning a 202 response, I include a
Retry-After header and a Location header. Clients can activate the
Location URI after the Retry interval expires. If the work is still in
process, the response is (again) a 202 w/ the same control data. At
some point the server will return a 200 (or possibly some 4xx/5xx code
as appropriate).

Is there a more appropriate solution?
- Using 302 instead of 202? Even in the first response to the POST/PUT/DELETE?
- Using Cache-Control:max-age instead of Retry-After?

Finally, is it considered harmful to use Retry-After and/or Location
headers w/ a 202 response?


[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0260.html
Received on Thursday, 3 June 2010 05:54:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:53 UTC