2015-11-06 21:39:33 +01:00
|
|
|
---
|
|
|
|
|
set: 2
|
|
|
|
|
code: 202
|
|
|
|
|
title: Accepted
|
2015-11-07 02:41:41 +01:00
|
|
|
references:
|
2015-11-07 06:01:00 +01:00
|
|
|
"Rails HTTP Status Symbol": ":accepted"
|
2015-11-06 21:39:33 +01:00
|
|
|
---
|
|
|
|
|
|
2015-11-09 01:28:54 +01:00
|
|
|
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.
|
2015-11-07 06:31:20 +01:00
|
|
|
|
2015-11-09 01:28:54 +01:00
|
|
|
There is no facility in HTTP for re-sending a status code from an asynchronous
|
|
|
|
|
operation.
|
2015-11-07 02:41:41 +01:00
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2015-11-09 01:28:54 +01:00
|
|
|
---
|
|
|
|
|
|
|
|
|
|
* Source: [RFC7231 Section 6.3.3][1]
|
2015-11-07 02:41:41 +01:00
|
|
|
|
|
|
|
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.3>
|
