0

lighttpd 1.4.31-4+deb7u3 automatically adds ;charset=UTF-8 to the content-type of .html and .php files.

How can I remove that?

Setting the content type in PHP itself does not help; lighttpd still adds the charset parameter - as soon as the mime type begins with text/.

Removing

 include_shell "/usr/share/lighttpd/create-mime.assign.pl"

from my config does also not help.

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
cweiske
  • 781
  • 1
  • 13
  • 36

2 Answers2

0

Lighttpd doesn't touch the Content-Type returned by a backend.

The charset is already set by php, see ini.default-charset

Stefan
  • 819
  • 1
  • 7
  • 18
  • the .html files are not processed by php at all. – cweiske Nov 08 '15 at 15:23
  • I don't see `charset` in [create-mime.assign.pl](http://sources.debian.net/src/lighttpd/1.4.31-4%2Bdeb7u3/debian/create-mime.assign.pl/) - maybe show us the response headers from `curl -v`. – Stefan Nov 11 '15 at 06:11
0

You need to edit /etc/php.ini and add this line:

default_charset = ""

They changed the behavior recently to automatically add UTF-8. What's worse, they auto-add Content-type[sic] instead of the correct capitalized ...Type which causes the header to get ignored in some versions of Chrome.

The decision obviously breaks configs with different encodings contained in the HTML itself.

Zdenek
  • 240
  • 1
  • 4
  • HTTP headers are by definition case-insensitive. – cweiske Mar 26 '17 at 19:29
  • Also, I already wrote in a comment to the other answer that PHP is not used for .html files - so it must be inside lighttpd. – cweiske Mar 26 '17 at 19:30
  • I'd like to see your source of said "definition." They have certain mandatory capitalization. And I didn't even claim anything about standards, I wrote the status quo. As for the other point, do check your php.ini, you never know what processes what and running .html files through php is common. Other than that, check the mime configuration in your lighttpd.conf to make sure nobody added the charset to the text/html. I'd like to add that ASP.NET auto-corrects your headers' case while php does not. This may be the source of the belief that it doesn't matter. – Zdenek Mar 27 '17 at 20:04
  • https://tools.ietf.org/html/rfc2616#section-4.2 " Field names are case-insensitive." – cweiske Mar 28 '17 at 04:28
  • Well, they aren't in ~75% of the world thanks to Chrome. You either relish in your standards, or you learn how to deliver working products. For a website to work, you must pay attention to the capitalization. I'm trying to help you while you get offended for not being right. Have you even checked that php.ini? – Zdenek Mar 28 '17 at 17:03
  • where is the evidence for "some versions of chrome"? – cweiske Mar 29 '17 at 07:05
  • I can't find my source and I have just verified that the problem is not in the current version of Chrome. But seeing from a Google search that the dependency on the case of these headers pops up as a "bug" every now and then in different pieces of software, I'd still advise you to use the usual way of spelling them. This really got off-topic. What about the webserver sending utf-8? Was that resolved? – Zdenek Mar 30 '17 at 16:11