Skip to content
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 #60

Closed
annevk opened this issue Apr 20, 2018 · 18 comments

Comments

Projects
None yet
4 participants
@annevk
Copy link

commented Apr 20, 2018

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

This comment has been minimized.

Copy link
Author

commented 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

This comment has been minimized.

Copy link
Contributor

commented Apr 20, 2018

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

@annevk

This comment has been minimized.

Copy link
Author

commented Apr 20, 2018

Care to elaborate?

@reschke

This comment has been minimized.

Copy link
Contributor

commented Apr 21, 2018

  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 mnot added the semantics label Jun 29, 2018

@mnot

This comment has been minimized.

Copy link
Member

commented 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

This comment has been minimized.

Copy link
Author

commented 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

This comment has been minimized.

Copy link
Contributor

commented 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

This comment has been minimized.

Copy link
Member

commented Jul 20, 2018

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

@reschke

This comment has been minimized.

Copy link
Contributor

commented 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

This comment has been minimized.

Copy link
Member

commented Oct 10, 2018

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

@mnot

This comment has been minimized.

Copy link
Member

commented Oct 10, 2018

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.

@mnot mnot added the has-proposal label Oct 10, 2018

@reschke

This comment has been minimized.

Copy link
Contributor

commented 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

This comment has been minimized.

Copy link
Member

commented 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

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2018

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

This comment has been minimized.

Copy link
Member

commented Oct 10, 2018

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

@reschke

This comment has been minimized.

@royfielding

This comment has been minimized.

Copy link
Member

commented Oct 10, 2018

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

This comment has been minimized.

Copy link
Member

commented Oct 10, 2018

WFM.

@mnot mnot closed this in cd801ea Oct 15, 2018

mnot added a commit that referenced this issue Oct 15, 2018

@mnot mnot removed has-proposal labels Oct 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.