Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

res.set() throws unexpected error when content-type is an array #3303

Closed
oztune opened this issue May 9, 2017 · 2 comments
Closed

res.set() throws unexpected error when content-type is an array #3303

oztune opened this issue May 9, 2017 · 2 comments

Comments

@oztune
Copy link
Contributor

oztune commented May 9, 2017

When I run this code:

res.set('content-type', ['application/json'])`

The following error is thrown:

TypeError: value.split is not a function

It seems to stem from the following line which assumes that the value of content-type will always be a string:
https://github.com/expressjs/express/blob/master/lib/response.js#L721

Is this a bug or a feature?

EDIT: Please let me know what the expected behavior is and I will be happy to submit a PR. I'm assuming we should either handle this error, or accept an array for 'content-type'.

@oztune oztune changed the title res.set() throws unexpected error when content-type is an array res.set() throws unexpected error when content-type is an array May 9, 2017
@dougwilson
Copy link
Contributor

Hi @oztune I would say that accepting an array doesn't even make sense, and since this code has been there for all of 4.x, providing an array would have always been an error. I think that this is a good change, in that we should add a guard that throws a better error message when a non-string is provided for content-type.

My reasoning is that it's easier to loosen a restriction than to add it back later, so if there ever is some demand for an array, we can easily add that, but I can't think of any reason an array would make sense in this header, unless you know.

Please feel free to make a PR :) !

@oztune
Copy link
Contributor Author

oztune commented May 10, 2017

@dougwilson I agree, I'll make a PR that throws a more sensible error. My use-case was that I'm proxying a node-fetch response over to an express response, and a very special API error was causing this odd failure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants