Reason phrase

[annevk]

It would be good to clarify two things:

1. Reason phrase is an optional part of the protocol and new wire formats must exclude it.
2. When a wire format excludes it, (legacy) APIs must use the empty string for it.

I don't have tests for 2 unfortunately, but there's rough agreement in whatwg/fetch#599, including it seems from mnot, that it's a good approach.

[annevk]

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]

I don't think I agree with 1 or 2.

[annevk]

Care to elaborate?

[reschke]

1. It is optional, but I don't see why we would require it to be excluded from new formats.
2. I also do not see why we would make API requirements.

[mnot]

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]

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]

What's the harm of proxies inserting something here?

(FWIW: my choice would have been not to remove it in HTTP/2)

[mnot]

Because it's an attractive nuisance - applications think it's an end-to-end signal, and it's not.

[reschke]

It is, but I think the confusion we have caused by not having it in HTTP/2 far outweighs any potential benefit.

[mnot]

Even before H2, it wasn't reliable; some implementations overwrite whatever is put in there.

[mnot]

Currently in Messaging - Status Line:

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.

[reschke]

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]

+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]

Not intended to be a requirement. Ought (should?) we revert all of the "ought"s to "should" if we adopt RFC8174?

Not sure. Might be easier to stick to the approach we have.

[mnot]

Changing ought to should would allow us to escape from RFC6919's baleful glare...

[reschke]

https://en.wikipedia.org/wiki/Wikipedia:If_it_ain%27t_broke,_don%27t_fix_it

[royfielding]

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).

[mnot]

WFM.