Ist die Verwendung des Location-Headers in der HTTP 202-Antwort RFC-kompatibel?

Ich habe eine großartige konzeptionelle Diskussion mit meinen Mitarbeitern über die Verwendung des Location-Headers in 202 Accepted response.

Die Geschichte begann mit der Analyse des Verhaltens der PHP-Funktion header () vonHie. Der interessante Auszug:

Der zweite Sonderfall ist der Header "Location:". Dieser Header wird nicht nur an den Browser zurückgesendet, sondern es wird auch ein REDIRECT (302) -Statuscode an den Browser zurückgegeben, es sei denn, der 201- oder 3xx-Statuscode wurde bereits festgelegt.

They hat in diesem Standardverhalten keinen 202-Statuscode eingeschlossen. Anscheinend erwarten sie nicht, dass die Antwort 202 einen Ort hat, und in der Tat:

header("HTTP/1.1 202");
header("Location: http://example.com");

Client an Standort-URL weiterleiten. Natürlich ist es möglich, dieses Verhalten mit dem dritten Parameter der header () - Funktion zu ändern, aber was hat meine Aufmerksamkeit erregt: Warum haben sie verstanden, dass standardmäßig nicht erwartet wird, dass 202 einen Location-Header enthält?

Dann überprüfe ich die RFC Suche nach der offiziellen Bedeutung von 202 Status. Der interessante Auszug:

Die mit dieser Antwort zurückgegebene Entität MUSS eine Angabe des aktuellen Status der Anforderung und entweder einen Zeiger auf einen Statusmonitor oder eine Schätzung enthalten, wann der Benutzer damit rechnen kann, dass die Anforderung erfüllt wird.

Es wird nicht explizit auf den Location-Header verwiesen, wie dies bei der vorherigen Antwort (in demselben RFC-Dokument) 201 der Fall ist. Das wäre wahrscheinlich der Grund, warum PHP-Leute verstanden haben, dass die Antwort 202 nicht den Location-Header enthalten sollte. Würde ein Zeiger als Location-Header interpretiert oder würden PHP-Leute eine falsche Annahme machen? Wenn der Standard Location-Header mit 202 Antworten zulässt: Sollte die offizielle Dokumentation nicht expliziter sein als die Definition von 201 Antworten?

Schließlich habe ich die meisten kürzlich RFC version und finde eine kleine Änderung in der Redaktion:

Die mit dieser Antwort gesendete Darstellung sollte den aktuellen Status der Anforderung und @ beschreibepoint to (oder embed) ein Statusmonitor, der dem Benutzer eine Schätzung darüber liefert, wann die Anforderung erfüllt wird.

Again es ist nicht explizit genug anzunehmen, dasszeigen au steht für Location Header.

Kurz gesagt, nach den obigen Überarbeitungen: Bin ich RFC-konform, wenn ich Location-Header mit 202 Antworten verwende?

Antworten auf die Frage(4)

Ihre Antwort auf die Frage