Is there a reason this library doesn't support charset as a parameter on Accept header?

[Paul Brabban]

Nice lib! Thanks for sharing it.

is there any reason it doesn't support a charset parameter on the accept header?

eg. Accept: 'application/json;charset=utf-8'

I might be able to put something together but I don't want to waste my time if there's a good reason it's not supported!

Thanks

[Douglas Wilson]

Can you define in what way it's not supported? As far as I know, we support it just fine. Can you show what code you tried to write, etc.?

[Douglas Wilson]

It is also very important to note that if you are looking at the charset in the Accept header, you're kind of falling outside of the HTTP spec; you should be negotiating charset using the Accept-Charset header instead.

[Paul Brabban]

Hi Doug, thanks for the response. Sorry, I should have explained more or written a test - it's quite possible I've misunderstood something!

Given my request containing Accept: application/json;charset=iso-8859-1, the following code wired in as a Hapi onPreHandler...

var negotiator = new Negotiator(request);
var charset = negotiator.charsets(['utf-8']);
console.log(charset);

produces utf-8for negotiator 0.5.3.

Thanks for the tip on specs - you're quite right, it may be something that should be optional in your lib rather than mandatory (if supported at all)?

[Douglas Wilson]

Ah, I see your misunderstading now--.charset and related methods are only for the HTTP Accept-Charset header (see https://github.com/jshttp/negotiator#accept-charset-negotiation) -- they have nothing to do with the Accept header, which is media type negotiation (using the .mediaType methods).

[Paul Brabban]

Whether or not the charset parameter in the accept request header is valid per the specs seems to be a bit open to interpretation, as per http://stackoverflow.com/questions/7055849/accept-and-accept-charset-which-is-superior - it's certainly not forbidden, section 3.7 of http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html says that accept and content type share the same definition of media type including parameters, and http://tools.ietf.org/html/rfc2046#section-4.1.2 states that the charset parameter is valid against the content-type media type!

I can understand why you might choose not to support it - would you consider PRs to introduce it maybe as an optional capability? Not saying that I'll have time to do that but in case I do!

Appreciate your time here btw.

[Douglas Wilson]

I'm not saying you cannot do it, but you just have to use the .mediaType methods to get at the Accept header; I would not accept modifying the .charset methods in any way to pull from there, especially because the parameters on media types are defined by them, so not all media types even allow a charset parameter, and even if they do, they can define it in any way (all RFC references need to be to 7230 or higher for HTTP/1.1--not RFC 2616, which is deprecated and obsoleted). Also, remember that the Content-Type header is very different from the Accept header, though parameters are of course acceptable in both :)

What is the specific reason you cannot use the Accept-Charset header, anyway?

[Douglas Wilson]

A good example of why .charset methods cannot look into the Accept header is because if you have the header Accept: application/json; charset=UTF-8, test/html; charset=iso-8859-1, you cannot possibly know which charset the client actually wants without first doing a media type negotiation, which is what the .mediaType methods are for.

[Paul Brabban]

I didn't realise those RFCs were deprecated. Thanks for clearing that up!