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-07 06:31:20 +01:00
|
|
|
The 202 Accepted status code indicates that the request has been accepted for
|
2015-11-07 02:41:41 +01:00
|
|
|
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
|
2015-11-07 06:31:20 +01:00
|
|
|
actually takes place.
|
|
|
|
|
|
|
|
|
|
There is no facility in HTTP for re-sending a status code
|
2015-11-07 02:41:41 +01:00
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Source: [RFC7231 Section 6.3.3][1]
|
|
|
|
|
|
|
|
|
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.3>
|
