在 HTTP 202 响应中使用 Location 标头是否符合 RFC? [英] Is the use of Location header in HTTP 202 response RFC-compliant?
问题描述
我与我的同事就在 202 Accepted 响应中使用 Location 标头进行了一场精彩的概念性讨论.
故事从 4.1 的作者(J. Snell)给出了一个在 202 Accepted response 中使用 Location 头的例子.他错了吗?好像很多人都从 RFC 7231 中理解了这种行为.你能给我发一些关于这个有争议的问题的参考吗?
罗伊: 这个例子没有说明，所以他没有错因为他没有说这意味着什么.位置可以在任何发送信息.其含义仅针对某些状态码定义.
例如，如果他说用户代理会使用该 Location 字段为用户提供状态指示符，然后他会错的.这可能是个好主意，但事实并非如此标准的一部分.
PHP 错误地假设 Location 仅用于 201 和3xx 响应，但允许这样做，因为它的内部 API不是 HTTP；它会将流转换为 HTTP.
没有争议.为了成为标准的一部分，在至少两个独立的实现必须显示相同行为.在这种情况下，没有人会这样做.
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 header() function from here. The interesting excerpt:
The second special case is the "Location:" header. Not only does it send this header back to the browser, but it also returns a REDIRECT (302) status code to the browser unless the 201 or a 3xx status code has already been set.
They didn't include 202 status code in this default behavior. It seems like they don't expect that 202 response has a Location and indeed:
header("HTTP/1.1 202");
header("Location: http://example.com");
redirect the client to Location URL. Of course, it is possible to change this behavior with third parameter of header() function but what attracted my attention was: Why they understood that by default 202 is not expected to hold a Location header?
Then I review the RFC looking for the official meaning of 202 status. The interesting excerpt:
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.
It doesn't explicitly refer to Location header like previous (in the same RFC doc) 201 response does. That would probably be the reason why PHP guys understood that 202 response should not hold Location header. Would a pointer be interpreted as Location header or PHP guys made a wrong assumption? If the standard allow Location header with 202 response: should not be the official documentation more explicit like 201 response definition?
Finally I reviewed the most recently RFC version and find a little change in redaction:
The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that an provide the user with an estimate of when the request will be fulfilled.
Again it is not explicit enough to assume that point to means Location header.
In short, after above revisions: Am I being RFC-compliant using Location header with 202 response?
Finally, I received a response from R. Fielding:
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.
这篇关于在 HTTP 202 响应中使用 Location 标头是否符合 RFC?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
