I have a great conceptual discussion with my coworkers about the use of Location header in 202 Accepted response.
The story began analyzing the behavior of PHP heade
From RFC-2616:
The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.
I think the key here is, "the entity", since the question here is whether we include the status indication in the response headers or in the response body. Almost everywhere an entity is referred to, it seems to imply the response body. For example:
10.5 Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method.
I haven't seen a browser ever display response headers to a user. And for 303s:
10.3.4 303 See Other
The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
You won't get a hypertext response in headers.
However, section 7 is quite clear about what the entity refers to:
An entity consists of entity-header fields and an entity-body, although some responses will only include the entity-headers.
I think that in your case, what you are doing is RFC-2616-compliant. However, realistically this all comes down to client implementation. Can the client receiving your 202 response handle a Location:
header for a 2xx
response? That should be your litmus test for how to respond, and is also the test used to drive standards during their standardization/documentation.