http-party
Can I specify the response charset?
hi, I find the file http-server serve is returned with content-type 'charset=utf-8', can I config to return with other charset i.e 'charset=gbk' ？
Just traced back a fairly subtle bug to the incorrect addition of charset=utf-8 to JPEG files.
+1 for a way to customize charset, but I believe the utf-8 charset should not be applied to images by default this way either.
Demo: imagebitmap-worker-test.zip
npm install
# Works correctly.
npx serve .
# Image is not shown in Firefox.
npx http-server .
My demo takes a very roundabout way of rendering the image ... normal <img src="..."> works just fine with the same charset, but nevertheless the charset seems to break Firefox.
Also note that because of this bug, loading an image via fetch() API (e.g. for use with createImageBitmap) will fail in Firefox. https://bugzilla.mozilla.org/show_bug.cgi?id=1413806. In fairness to Firefox, it's arguably doing the right thing.
Any suggestions on this, or on what sort of PR would be accepted? If not a way to specify response charset, could we not default to utf8 for images?
This line in node-ecstatic is the actual culprit: https://github.com/jfhbrook/node-ecstatic/blob/1b5692c5ae3af10018d9c1d4a9ff3a1a7ee6be01/lib/ecstatic.js#L243
It sets utf-8 as the default charset when doing the lookup--rather than leaving it off (which should be the default, probably).
Relatedly, the mime package which node-ecstatic uses has a new major point release (2.0) and removes the charset detection altogether preferring a single getType().
Simple solution would be to change the default behavior of node-ecstatic from setting charset=utf-8 followed by a more "complex" (but better long term) solution of upgrading the mime package to ^2.0.0.
Either way, I'm afraid it's an upstream bug...though I'm on my way to make this request there, and would appreciate a 👍. 😄
Related issue at node-ecstatic https://github.com/jfhbrook/node-ecstatic/issues/220
@donmccurdy here's the upstream PR if you'd like to test and 👍 it: https://github.com/jfhbrook/node-ecstatic/pull/223
@BigBlueHat thank you! 😃 It's likely to be a few days before I can test this but the changes look good. Code to reproduce the issue is included above (https://github.com/indexzero/http-server/issues/296#issuecomment-338352458) if someone else has the chance before I do.
Confirmed that the change (https://github.com/jfhbrook/node-ecstatic/pull/223) fixes the issue and Firefox can load the image correctly. 🎊
@donmccurdy thanks for that confirmation! It looks like we're all waiting on getting the mime library migration done well--as they deprecated the ability load .types files (which Apache, etc, use for storing their mime databases). See more here: https://github.com/jfhbrook/node-ecstatic/pull/223#issuecomment-401414852
That upstream situation is the same as our downstream one--i.e. I'm not keen to stop supporting the .types database loading...but there's not currently a standalone library to do that (afaict).
I just filed an issue to bring back ye olde .load() feature (possibly as a standalone module):
https://github.com/broofa/node-mime/issues/210
There's also similar code available in an alternative mime-database-in-JSON module: https://github.com/jshttp/mime-db/tree/master/scripts
Those aren't currently exposed as modules, though, they're just used to generate the JSON file.
...data formats are the death of computing...
If anyone here feels like saving the day, we'd just need a module to convert .types mime database files into JSON format(s).
Sorry it's not an easy fix... 🎩
I believe this may be solved by the joint efforts of improved charset detection in #736 and the option to specify default content type in #288. I'll mark #288 as fixing this issue
