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

Use uppercase first letter in HTTP header keys #16

Open
florianbehrens opened this issue Oct 7, 2015 · 2 comments
Open

Use uppercase first letter in HTTP header keys #16

florianbehrens opened this issue Oct 7, 2015 · 2 comments

Comments

@florianbehrens
Copy link
Contributor

Any HTTP server I know (but, honestly, I don't know many) use uppercase first letters in HTTP header keys (e.g., 'Transfer-Encoding' rather than 'transfer-encoding').

@vinipsmaker
Copy link
Member

From a "pure" point of view, there is nothing wrong with what I'm doing and I'd like to say "no, I won't fix that" with a load of arguments back to you.

But... you might want to obfuscate the fact that you're using Boost.Http (there are several reasons to do that). So I'm not going to reply that with "won't fix" (even if I want to).

If I only see what is relevant for this issue, the headers are present in Boost.Http at two different layers. The first layer is the user layer and I'll definitively not change that because of a silly reason like this (and this would be a change that doesn't even make sense to all HTTP backends).

The second layer is the specific implementation basic_socket, a model of the Socket concept. I could add a "policy" (or other term, if you may) template argument to this socket in which I could put an enum where the user could choose to send "all lowercase", "all uppercase" or "Camel-Case". I already plan to introduce this "policy" to specify parser options like "maximum header size" and others.

@florianbehrens
Copy link
Contributor Author

ACK...seems to be a reasonable solution.

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

No branches or pull requests

2 participants