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

Re: Revisiting Retry-After w/ 202

From: mike amundsen <mamund@yahoo.com>
Date: Thu, 3 Jun 2010 02:28:24 -0400
Message-ID: <AANLkTikqzLXha08psNgXG1fx6eouWgGDT_838Mmxvho0@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:20 GMT