Node-restify: Sending a buffer rewrite content-type header

[sonnyp]

Sending a buffer rewrite previously set content-type header to 'application/octect-stream'.
Either by setting the content-type with req.contentType property or req.header method.

restify 2.7.0

var buffer = ...
var type = 'image/png';

server.use(function(req, res) {

    res.header('content-type', type);
    //prints true
    console.log(res.header('content-type') === type);
    res.send(buffer);
    //prints false
    console.log(res.header('content-type') === type);

});

[kierans]

This bit me too when I wrote a string to res.send()

[jessezhang91]

I'm experiencing this issue as well but found the following workaround:

res.send(buffer, {
    'content-type': type
});

I think the issue comes from res.format which sets the content-type to application/octet-stream if no formatter is found and forces that content-type onto the response. Luckily, the headers provided within res.send is set after res.format.

[micahr]

@jessezhang91 You are correct, there is a bug in the res.format method that causes application/octet-stream to be defaulted to if there isn't a formatter present.

[kevinpeno]

Based on the original request, the user was setting res.header('content-type', type); directly. Why would passing a buffer to res.send change the content-type header for the user?

The last comment on this thread claims there is a bug that sets application/octet-stream if no other formatter is present. This seems correct (and/or we should follow the default for HTTP spec).

If this is how it worked at one point, and was later broken, we should document it. If I'm misunderstanding, what is the bug here and what is to be corrected?

[jessezhang91]

I may be remembering this incorrectly now but I think the issue was that despite a content-type being set, passing a buffer to res.send would change the content-type to application/octet-stream.

Perhaps it is simply a documentation issue but my assumption was setting the content-type and sending a buffer would send a response with the content-type not application/octet-stream.

[kevinpeno]

Thanks for the clarification. Some of the comments eluded to your point, but at times I felt like the opposite was being requested (always send application/octet-stream with buffer).

I'll review the current test suite and docs to see if I can find if the inconsistency still exists with the current versions.

[DonutEspresso]

I believe the behavior being exhibited is expected. I think the original problem was that a formatter was not defined for the content-type, thus falling back on application/octet-stream. AFAICT this holds true no matter what you pass to res.send. You can define a passthrough formatter for your content-types that basically flushes the buffer and you're good.

Thanks all for following up. Closing unless I hear otherwise!