Skip to content

Consistently capitalized all instances of Content-* headers #7577

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

Closed
wants to merge 1 commit into from

Conversation

vedranmiletic
Copy link
Contributor

Replaced Content-type and Content-length with Content-Type and Content-Length for consistency with the rest of the codebase. Additionally, while HTTP/1.1 headers are case-insensitive according to the RFC 2616, the capitalization used in the document is Content-Type and Content-Length.

Tested locally on the default build configuration and no breakages have been observed.

Replaced Content-type and Content-length with Content-Type and
Content-Length for consistency with the rest of the codebase.
Additionally, while HTTP/1.1 headers are case-insensitive according to
the RFC 2616, the capitalization used in the document is Content-Type
and Content-Length.
Copy link
Member

@nikic nikic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a harmless change, but also not a particularly useful one. @cmb69 Do you see any issues with doing this?

@vedranmiletic
Copy link
Contributor Author

@nikic thanks, I know it's not anything major. I'm using PHP for teaching how HTTP works and it would be nice to have the headers appear in a consistent manner.

@kamil-tekiela
Copy link
Member

I was thinking of proposing the same, but I decided it wasn't worth my time. I see nothing wrong with changing the capitalization.

@cmb69
Copy link
Member

cmb69 commented Oct 14, 2021

I'm very much with @nikic here. The potential BC break for code and tests assuming case-insensitive headers is slightly concerning; OTOH, this might a chance for such code to be fixed. Maybe write to the internals list?

@krakjoe
Copy link
Member

krakjoe commented Oct 19, 2021

There is potential for breakage and very low value in the change itself.

Because of that, I'm closing this one.

If you want to start a conversation about it on internals, this may be re-opened if the consensus gathered there is different to the apparent consensus here.

Thanks for putting in the effort.

@krakjoe krakjoe closed this Oct 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants