Larry, hello.

On 12 May 2020, at 16:33, Larry Martell wrote:

> There can be cases when a
> request from a user does not come back from the db for 15-20 minutes.
> This is expected as it's calling a stored proc that does a lot and
> this is an internal app.

(open-parenthesis

This isn't an answer to your question, but that sort of interaction does
go pretty much against the grain of the HTTP protocol, and the 'REST'
interaction style that it led to, so there may be architectural reasons,
rather than merely implementation ones, for this application to have
further problems, further down the line. If a proxy were ever to be
involved, you'd acquire a separate set of headaches.

There is an HTTP response code '202 Accepted' (which is a success code,
of course), glossed as 'The request has been accepted for processing,
but the processing has not been completed' -- details below. That's
pretty much intended for just this sort of interaction. The idea is
that the server would respond promptly with 202, perhaps with a
retry-after header, and the client knows to try again later, possibly
repeatedly, until it gets either a 200 or a 4xx.

Of course, this would require changes at server and client end, so it's
not immediately helpful.

Good luck,

Norman

close-parenthesis)



The text of RFC 7231 says:

6.3.3. 202 Accepted

The 202 (Accepted) status code indicates that the request has been
accepted for processing, but the processing has not been completed.
The request might or might not eventually be acted upon, as it might
be disallowed when processing actually takes place. There is no
facility in HTTP for re-sending a status code from an asynchronous
operation.

The 202 response is intentionally noncommittal. 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. The representation sent with this
response ought to describe the request's current status and point to
(or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled.

--
Norman Gray : https://nxg.me.uk
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx