Add charset=utf-8 to Content-Type for CSS and HTML assets#264
Open
flavorjones wants to merge 3 commits intorails:mainfrom
Open
Add charset=utf-8 to Content-Type for CSS and HTML assets#264flavorjones wants to merge 3 commits intorails:mainfrom
flavorjones wants to merge 3 commits intorails:mainfrom
Conversation
4 tasks
Minitest 6 split minitest/mock into a separate gem, which breaks tests that require "minitest/mock". Pin to < 6 in the Gemfiles where this causes failures. Rails 7.2 is unaffected (it constrains minitest itself).
This comment was marked as outdated.
This comment was marked as outdated.
CSS and HTML assets served by Propshaft::Server now include "; charset=utf-8" in their Content-Type response header. This fixes browser encoding issues where non-ASCII characters in CSS files (e.g., en-dash in content properties) render as mojibake when Chrome falls back to Windows-1252 encoding.
flavorjones
force-pushed
the
fix-css-content-type
branch
from
c5cbc65 to
d28d07f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note: this branch was based on #265 to get CI green.
Motivation / Background
CSS files served by
Propshaft::ServerhaveContent-Type: text/csswith nocharset=utf-8. When Chrome discovers a stylesheet via<link>tag during HTML parsing (rather than viaLink: rel=preloadheader), it may inherit the document's encoding or fall back to Windows-1252 instead of defaulting to UTF-8. This causes non-ASCII characters in CSS (e.g., en-dash U+2013 incontentproperties) to render as mojibake.The same issue affects HTML assets.
The CSS spec defaults to UTF-8, but Chrome has a longstanding bug where it doesn't reliably follow this default. Adding
charset=utf-8to the Content-Type header is the highest-priority encoding signal in the spec's detection chain.Companion Rails PR: rails/rails#57188
Detail
Propshaft::Server#callnow appends; charset=utf-8to the Content-Type header fortext/cssandtext/htmlassets. Only these two MIME types are affected —text/javascriptis excluded per RFC 9239,text/xmlcould break encoding declarations, andtext/plainhas no demonstrated browser bug.Additional information
ActionDispatch::Responsealready addscharset=utf-8unconditionally to all controller responses, butPropshaft::Serverbuilds its own Rack response and bypasses that path. This fix closes that gap for CSS and HTML assets in development.