charset=utf8 inserted between two phrase media type in response header

[nicholasf]

Hi,

Express is mangling the response header I'm trying to set for a two phrase media type

We are establishing a HATEOAS convention where we have a generic collection type, designated as a vnd, and various media types which might be collected there, also a vnd.

res.set('content-type', 'application/vnd.samcorp.collection;content="application/vnd.samcorp.foo"');

Read this as - we are sending you a samcorp collection of samcorp.foos.

Express renders the header as:

HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/vnd.samcorp.collection; charset=utf-8; content="application/vnd.samcorp.foo"
...

Is there a way I can get rid of the intruding charset header?

It's worth noting that I had to do a lot of googling to discover how to include the content specifier. Using what is below results in an invalid parameter error from Express, so the double quotations in what was above became necessary.

 res.set('content-type', 'application/vnd.samcorp.collection;content=application/vnd.samcorp.foo');

Thanks,
Nicholas

[dougwilson]

Hi! This is expected behavior and is 100% to the HTTP specification to how the Content-Type header works. If your client is confused by the re-formatting, then it has a buggy implementation and does not follow the HTTP specifications correctly.

That said, if you simply want to avoid us adding the charset parameter to your Content-Type header, you have to methods:

1. Provide a Buffer object to res.send instead of a string. We will not add the charset parameter, because we are not doing any encoding to your response.
2. Skip using res.send altogether and use the lower-level Node.js res.write/res.end methods.

I hope this helps!

[nicholasf]

@dougwilson thanks, yeh, it does. I'll delve into the two options you suggest. Thanks for offering them.

[dougwilson]

No problem! This is a case where Express is adding sugar through things like res.send and res.json, and trying to ensure that your responses are a spec-compliant as possible (which is why you also had to quote the second type, as it contained characters that were not valid as a parameter value unless quoted), is conflicting with something you are trying to achieve.

The way we usually recommend attacking this is to report here so we can double-check that it makes sense from a spec point-of-view (which it looks like it does based on your report) and offer the methods to avoid the sugar :)