Re: 202 Response to GET request

Yes I understand the GET is safe. My question / point, is 202 valid for a
safe method that is doing no work?


On Sun, Oct 6, 2013 at 11:34 AM, Jan Algermissen <[email protected]
> wrote:

>
> On 05.10.2013, at 20:15, Glenn Block <[email protected]> wrote:
>
> > Yes on querying the resource but isn't that the entire reason for
> returning the monitor uri? ie 'go here to check the status' ?
>
> Hmm, yes. But I meant that the GET on the PDF-URI is still idempotent and
> safe from the POV of the client ... even if the first GET starts the
> generation and returns a 202.
>
> However, it was all just a remark in what case you *might* maybe uses a
> 202 for a GET :-)
>
> Jan
>
> >
> > On Saturday, October 5, 2013, Jan Algermissen wrote:
> >
> >
> > On 05.10.2013, at 20:01, Glenn Block <[email protected]> wrote:
> >
> > > Hmm, you are suggesting it is valid, I read as relating to an unsafe
> method ie that performs some work.
> >
> > Yes - that is why I wrote 'Maybe' :-) However, the GET would still be
> idempotent and safe - the client can safely call the GET on the pdf URL as
> often as it wants and the fact that a background process has been started
> for the first GET is not of concern to the client.
> >
> > All that with some caveat, I am not sure I'll agree with this in a
> couple of hours :-)
> >
> > Jan
> >
> >
> > > GET is always safe, I agree querying for a status is not causing a
> side effect but still.
> > >
> > > On Saturday, October 5, 2013, Jan Algermissen wrote:
> > >
> > > On 05.10.2013, at 19:21, Glenn Block <[email protected]> wrote:
> > >
> > > > Seems very odd for the reasons you cited, 202 says your request has
> not been processes. The spec also speaks about the location uri pointing to
> a monitor. I would not expect the status code of that monitor to be a 202
> either.
> > >
> > > No, that resource provides you with information about the status of
> the processing of the other request.
> > >
> > >
> > > Maybe:
> > >
> > > GET /account/jim/downloads/someLargeBoolAsPdf.pdf
> > >
> > > 202 Accepted
> > > Location: /account/jim/downloads
> > > Content-Type: text/plain
> > >
> > > Thank you for requesting this download - you PDF is being created.
> Please visit your downloads overview page to check the status of the PDF
> generation.
> > >
> > >
> > >
> > > Jan
> > >
> > >
> > >
> > > >
> > > >
> > > > On Saturday, October 5, 2013, Unmesh Joshi wrote:
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I recently came across an API which was returning '202 Accepted'
> response to GET request. It seemed a bit odd.
> > > > Most asynchronous operations on HTTP implemented with POST request
> and 202 response.
> > > > While HTTP does not mandate 202 response to be returned only to POST
> requests, following lines in RFC do indicate, its almost always going to
> POST.
> > > >
> > > > "The 202 response is intentionally non-committal. Its purpose is to
> allow a server to accept a request for some other process. (perhaps a
> batch-oriented process that is only run once per day) without requiring
> that the user agent's connection to the server persist until the process is
> completed. "
> > > >
> > > > Have anyone come across implementations using 202 response for GET?
> > > >
> > > > Thanks,
> > > > Unmesh
> > > >
> > > >
> > > >
> > >
> >
> >
> > 
>
>