- From: mike amundsen <mamund@yahoo.com>
- Date: Thu, 3 Jun 2010 02:28:24 -0400
- To: Jan Algermissen <algermissen1971@mac.com>
- Cc: ietf-http-wg@w3.org
<snip> > Returning the 202 is wrong in the case of a GET to the status resource. </snip> I am not able to confirm that 202 response is invalid for GETs from the description of 202 Accepted [1] or GET [2] and only find reference to 202 as a response code under DELETE [3] and as an alternate for 201 Created [4]. <snip> > What is the problem with defining an appropriate 202 body media type for non-GUI user agents? After all, you tie your user agent code to your special header combinations and associated expectations anyway. </snip> No problem; as I indicated in my message, I do the very thing you suggest regularly. My question is about whether this alternate/additional solution is harmful or problematic. For example, it screws up intermediaries, etc. mca http://amundsen.com/blog/ http://mamund.com/foaf.rdf#me [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3 [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3 [3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7 [4] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2 On Thu, Jun 3, 2010 at 02:10, Jan Algermissen <algermissen1971@mac.com> wrote: > > On Jun 3, 2010, at 7:53 AM, mike amundsen wrote: > >> 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). > > Returning the 202 is wrong in the case of a GET to the status resource. > >> >> Is there a more appropriate solution? > > What is the problem with defining an appropriate 202 body media type for non-GUI user agents? After all, you tie your user agent code to your special header combinations and associated expectations anyway. > > Jan > >> - 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? >> >> mca >> http://amundsen.com/blog/ >> http://mamund.com/foaf.rdf#me >> >> [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0260.html >> > > ----------------------------------- > Jan Algermissen, Consultant > NORD Software Consulting > > Mail: algermissen@acm.org > Blog: http://www.nordsc.com/blog/ > Work: http://www.nordsc.com/ > ----------------------------------- > > > > >
Received on Thursday, 3 June 2010 06:28:58 UTC