Content-Type charset handling not working

[etnt]

It seem like Yaws doesn't honor the default_charset (or the add_charsets ?) config when constructing the Content-Type header. A programmatic interface for manipulating this is also missing.

See also: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type

[vinoski]

Do you have a test case or example that shows the problem?

[etnt]

Well, by looking through the code I can't see it used anywhere.

And if you simply hard code default_charset to e.g "utf-8" in the #mime_types_info{} record (yaws.hrl), then recompile all code and run a HTTP request like:

> curl -k -is  https://localhost:8889/sitemap.xml | grep 'Content-Type:'
Content-Type: text/html

I would expect to get back:

Content-Type: text/html; charset=utf-8

As the docs state:

default_charset = Charset
              Defines the default charset to be added when a response content-
              type is text/*. By default, no charset is added.

Note: a workaround until this is solved could of course be to use the extra_response_header callback to append a charset for any outgoing 'Content-Type' header.

[vinoski]

You don't have to hard-code default_charset in yaws.hrl since you can specify the default charset in yaws.conf via

default_charset = UTF-8

See the mime_types_SUITE config file for example.

There's also the configure option --with-defaultcharset=CHARSET. I rebuilt Yaws using

configure --with-defaultcharset=US-ASCII

After this, accessing an HTML file returns

Content-Type: text/html; charset=US-ASCII

So I think the support that's present works as documented.

Regarding your issue about programmatic control, I'd need more details about what you'd like to be able to do.

[etnt]

Whaat!? Hm...I need to dig into this further. Btw: we are not using a yaws.conf file, we are strictly using Yaws in embedded mode and all config is done programmatically.

[etnt]

Ok, I see now. The mime_types.erl file is generated on the fly. This is unacceptable in our product (we don't even ship the compiler). I'll do a workaround for now, but I may rework this and perhaps make use of an ets table instead.

[vinoski]

Sounds good. I can definitely see your point about the lack of a compiler in some deployments, so having an alternative would be good for those cases.