-
Notifications
You must be signed in to change notification settings - Fork 967
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
feat: default to charset=utf-8 for text content type #554
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! This looks good to me.
@jplatte Do you wanna take a quick look as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me as well. I was a little worried about the extra dependency at first but I've had a quick skim of its docs & source and it really seems minimal (nothing like mime guessing based on magic bytes or file extensions in there) and is maintained by seanmonstar so doesn't even increase the potential for supply-chain attacks either.
One more thing I thought off: We should probably mention this in the changelog. |
I've fixed the comment and added the changelog |
@davidpdrsn Hi, thanks for your review! |
Head branch was pushed to by a user without write access
@davidpdrsn |
Motivation
When using axum, I found that if I returned content in non-English(e.g. Chinese), then all browsers (include Chrome, Safari, Firefox) will display unreadable chars.
After investigating, I found that this is because axum only returns
Content-Type: text/plain
instead ofContent-Type: text/plain; charset=utf-8
.I think adding
charset=utf-8
as the default charset fortext
content type makes sense.Solution
I added
charset=utf-8
as the default charset fortext
content type and used themime
crate to avoid repeat and hard code of header values.