Is the use of Location header in HTTP 202 response RFC-compliant?

Finally, I received a response from R. Fielding:

enter image description here

202 is a success status. The pointer mentioned is just hypertext in the body of the response.
A 303 should be sent if you want to use Location to redirect the client to another resource. The result of the redirected request can be a 202.

….Roy

So, the Location header should not be used in 202 Accepted response. The PHP guys did the right interpretation.

Edit March, 2017: Sorry, I forgot to add other messages we exchanged in the same thread at that moment so I am posting now for the record:

me: On the section 4.1 of the RFC 7240 the author (J. Snell) give an example using Location header in 202 Accepted response. Is he wrong? It is like many people understand this behavior from RFC 7231. Can you send me any reference about this controversial issue?

Roy: The example is given without instruction, so he is not wrong
because he doesn’t say what it means. Location can be sent in any
message. What it means is only defined for certain status codes.

For example, if he had said that the user agent would make use of
that Location field to provide a status indicator to the user, then
he would have been wrong. It might be a good idea, but it isn’t
part of the standard.

PHP makes a wrong assumption that Location is only used in 201 and
3xx responses, but it is allowed to do so because its internal API
is not HTTP; it translates the stream to HTTP instead.

There is no controversy. In order to be part of the standard, at
least two independent implementations would have to show the same
behavior. In this case, none do.

Leave a Comment

Hata!: SQLSTATE[HY000] [1045] Access denied for user 'divattrend_liink'@'localhost' (using password: YES)