New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reason phrase #202

Closed
reschke opened this Issue Aug 6, 2013 · 3 comments

Comments

Projects
None yet
3 participants
@reschke
Contributor

reschke commented Aug 6, 2013

8.1.2.:

"The response status line has been reduced to a single ":status" header field whose value specifies only the numeric response status code. The status text component of the HTTP/1.1 response has been dropped entirely."

Dropping the reason-phrase might break a few edge cases; is this worth it?

Maybe add a separate optional ":reason-phrase" header field?

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Oct 10, 2013

Member

Discussed in Seattle; no interest in carrying the reason phrase.

Member

mnot commented Oct 10, 2013

Discussed in Seattle; no interest in carrying the reason phrase.

@thurt

This comment has been minimized.

Show comment
Hide comment
@thurt

thurt Feb 4, 2018

i'm curious what was the logical reason for dropping the reason phrase?

i was using the reason phrase as a title for messages presented to a user in the web browser client. i think most users are accustomed to such phrases, "Bad Request", "Not Found", etc. Now I will just have to write a mapping from status codes to my own reason phrases in the client.

thurt commented Feb 4, 2018

i'm curious what was the logical reason for dropping the reason phrase?

i was using the reason phrase as a title for messages presented to a user in the web browser client. i think most users are accustomed to such phrases, "Bad Request", "Not Found", etc. Now I will just have to write a mapping from status codes to my own reason phrases in the client.

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Feb 4, 2018

Member

The reason phrase -- even in HTTP/1.1 -- isn't guaranteed to be carried end-to-end; implementations can (and do) ignore it and substitute their own values (e.g., 200 is always "OK", no matter what happens on the wire).

Given that, and overhead in carrying the extra bytes, it made sense to drop it from the wire.

Member

mnot commented Feb 4, 2018

The reason phrase -- even in HTTP/1.1 -- isn't guaranteed to be carried end-to-end; implementations can (and do) ignore it and substitute their own values (e.g., 200 is always "OK", no matter what happens on the wire).

Given that, and overhead in carrying the extra bytes, it made sense to drop it from the wire.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment