Use 'utf-8' instead of 'utf8' to be standard compliant.

[evantill]

Using 'utf8' is not compatible with some IE versions like IE9 (loading page throw a script error “c00ce56e”).

see this article on invalid charset

also see section "Official name and variants" in wikipedia and http://www.w3.org/International/O-HTTP-charset

Other descriptions that omit the hyphen or replace it with a space, such as "utf8" or "UTF 8", are not accepted as correct by the governing standards.

note: in html5boilerplate the charset is defined as utf-8

[RobLoach]

Looking through some of the node documentation, there are references to utf8. Buffer is an example of this. utf-8 works though. Very strange, I'd suggest going with what's commonly in the official node docs, I could be convinced otherwise.

[evantill]

we could keep utf8 for IO operations.
But for charset in http header this is a problem. utf-8 is the standard.

If we keep utf8 in headers, some browsers will not work with docpad.

So ?

[evantill]

as a counter example see Express. They use utf-8 every where.
response.js#L112

[RobLoach]

👍

[evantill]

like that ?

[RobLoach]

Oh, sorry, I was happy with using it everywhere 😀 . I suppose it's up to you and Ben!

[balupton]

For now, let's keep it for just the charset header 👍 Updating the others would mean we would also have to update https://github.com/bevry/istextorbinary/ in which utf8 is used within itself and the encoding/decoding dependency it uses. So the best approach appears to be just renaming to utf-8 only where it is essential (in this case charset header), and won't possibly break b/c, extensions, or start a snowball of renames across our own projects and all our dependencies.

@RobLoach loves his emoji's :)

[RobLoach]

⚡

[evantill]

Thanks.
I already changed the PR in this way. Can you confirm that this PR is ok like that ?

[evantill]

Thank you. I will test it next week.