You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tend to agree that the HTTP spec shouldn't be making hard requirements for APIs or tying the hands of future versions of the protocol in this way. That said, clarifying the optionality and unreliability of the reason phrase would be good.
I don't really agree. It seems a lot better if it's not optional, but is instead always the empty string in H/2. Otherwise you get proxies inserting it and such.
The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A client should ignore the reason-phrase content.
Suggest adding:
... A client should ignore the reason-phrase, because it is not transmitted in other versions of HTTP, and is overwritten by some HTTP/1.1 implementations. As such, it is not a reliable channel for information.
Umm, it is already an existing requirement. Uppercase.
A client SHOULD ignore the reason-phrase content.
I would change it to
A client SHOULD ignore the reason-phrase content because it is not a reliable channel for information (it might be discarded or overwritten by intermediaries).
Activity
annevk commentedon Apr 20, 2018
I should mention that I got some pushback on 2 in https://bugzilla.mozilla.org/show_bug.cgi?id=1397646, though the alternative proposed does not strike me as ideal (leaving this undefined).
reschke commentedon Apr 20, 2018
I don't think I agree with 1 or 2.
annevk commentedon Apr 20, 2018
Care to elaborate?
reschke commentedon Apr 21, 2018
mnot commentedon Jun 29, 2018
I tend to agree that the HTTP spec shouldn't be making hard requirements for APIs or tying the hands of future versions of the protocol in this way. That said, clarifying the optionality and unreliability of the reason phrase would be good.
annevk commentedon Jul 20, 2018
I don't really agree. It seems a lot better if it's not optional, but is instead always the empty string in H/2. Otherwise you get proxies inserting it and such.
reschke commentedon Jul 20, 2018
What's the harm of proxies inserting something here?
(FWIW: my choice would have been not to remove it in HTTP/2)
mnot commentedon Jul 20, 2018
Because it's an attractive nuisance - applications think it's an end-to-end signal, and it's not.
reschke commentedon Jul 20, 2018
It is, but I think the confusion we have caused by not having it in HTTP/2 far outweighs any potential benefit.
mnot commentedon Oct 10, 2018
Even before H2, it wasn't reliable; some implementations overwrite whatever is put in there.
mnot commentedon Oct 10, 2018
Currently in Messaging - Status Line:
Suggest adding:
reschke commentedon Oct 10, 2018
s/is not transmitted in other versions of HTTP/is not transmitted in some other versions of HTTP/
Also, "should ignore" - is that a SHOULD. What does it mean. Is it allowed to display it?
mnot commentedon Oct 10, 2018
+1 to the edit.
Not intended to be a requirement. Ought (should?) we revert all of the "ought"s to "should" if we adopt RFC8174?
reschke commentedon Oct 10, 2018
Not sure. Might be easier to stick to the approach we have.
mnot commentedon Oct 10, 2018
Changing ought to should would allow us to escape from RFC6919's baleful glare...
reschke commentedon Oct 10, 2018
https://en.wikipedia.org/wiki/Wikipedia:If_it_ain%27t_broke,_don%27t_fix_it
royfielding commentedon Oct 10, 2018
Umm, it is already an existing requirement. Uppercase.
I would change it to
mnot commentedon Oct 10, 2018
WFM.
Correct change log for #60.