You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Searched both open and closed issues for duplicates of this issue
Title adequately and concisely reflects the feature or the bug
Bug Report
When res.send is called, and a content-type is not explicitly set, application/json is chosen as the default content type if the first parameter received by send is a JS object. This behavior can be confusing (even more so when strictFormatters; false), and seems to be unnecessary given that res.json exists to do the same thing.
Something worth considering as we figure out how to decouple content negotiation from formatters moving forward.
I've just run into this and found it quite odd. I had thought that one of the benefits of Restify was that it will do content negotiation and yet most of the time it's application/json or nothing. (After all, most things in JavaScript are objects.)
In my case, I was considering returning HTML to browsers when a request results in an error. (Though I appreciate my use of Restify might be a little odd.)
It seems to me that for different things passed to res.send() it makes sense to prefer some content types over others but not to force them.
As things stand the first example on the getting started page appears to break as soon as one changes the value passed to res.send().
Bug Report
When
res.send
is called, and a content-type is not explicitly set, application/json is chosen as the default content type if the first parameter received bysend
is a JS object. This behavior can be confusing (even more so whenstrictFormatters; false
), and seems to be unnecessary given thatres.json
exists to do the same thing.Something worth considering as we figure out how to decouple content negotiation from formatters moving forward.
cc @misterdjules
The text was updated successfully, but these errors were encountered: