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

The built-in hardcoded mime types does not handle webfont file extensions correctly #2337

Closed
sean220 opened this issue Jun 22, 2022 · 4 comments

Comments

@sean220
Copy link

sean220 commented Jun 22, 2022

When using data-url loader to bundle webfont files in css,it failed to identify correct content-type.
actually:
url(data:text/plain;charset=utf-8;base64,ZGF0YTpmb250L3dvZm...
expected:
url(data:font/woff;charset=utf-8;base64,ZGF0YTpmb250L3dvZm...

After implementing my own onLoad plugin and returning the correct dataurl content,
it will eventually be modified to the wrong mime type.

@evanw
Copy link
Owner

evanw commented Jun 22, 2022

Hopefully the internal list should be easy to update. Do you just need .woff => font/woff? Anything else?

@sean220
Copy link
Author

sean220 commented Jun 22, 2022

.otf -> font/otf
.sfnt -> font/sfnt
.ttf -> font/ttf
.woff -> font/woff
.woff2 -> font/woff2
Other non-standard font formats are left as are:
.eot -> application/vnd.ms-fontobject
.svg -> image/svg+xml

2)When the content returned by the onload callback in plugin contains the mime type, and the loader is specified as dataurl, can the mime type not to be overwritten?

@evanw
Copy link
Owner

evanw commented Jun 22, 2022

Ah, I see. If you specify dataurl in onLoad, you are telling esbuild "here is a string that should be encoded as a data URL." So it's being wrapped in a data URL twice. It doesn't mean "here is a string that is already encoded as a data URL." Here's the URL in your example:

 url(data:text/plain;charset=utf-8;base64,ZGF0YTpmb250L3dvZm...

That's actually just the base64 encoding of your input:

> atob('ZGF0YTpmb250L3dvZm')
"data:font/wof"

I'm not sure quite what the best way to handle this is from within a plugin off the top of my head. Maybe having the URL be marked as external and for the external text to be the data URL? That way esbuild will leave it alone. But the easiest solution is for esbuild to just do it for you once the MIME types are updated.

@evanw evanw closed this as completed in 8b0da1d Jun 23, 2022
@sean220
Copy link
Author

sean220 commented Jun 24, 2022

I understand, this defect is that I return the encoded content of dataurl in onLoad, which causes it to be recognized as text/plain in esbuild. After change to return rawdata,although not recognized by hardcoded mimetypes,but it is correctly handled by http.DetectContentType([]byte(contents))
But webfonts are common import type in css, adding built-in mimeTypes should improve some performance, thanks again.

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