Repository navigation
HttpServerResponse.setDefaultEncoding() #14146
Description
Activity
Nor does
ServerResponseorOutgoingMessageimplementcorkoruncork...If it makes sense to implement these non-existent functions both for
ServerResponseand forOutgoingMessage, I'd like to take a crack at it!From my understanding, something in the lines of
util.inherits(ServerResponse, stream.Writable);would suffice?@joaolucasl Guess this simple line won't suffice according to this note in docs on Class: http.ServerResponse:
The response implements, but does not inherit from, the Writable Stream interface. This is an EventEmitter with the following events:
Nonetheless, this statement is wrong since setDefaultEncoding(), cork() and uncork() are part of Writable interface.
Aside from that I second this issue. Any fix might help me with issues I'm facing when piping from same source into ServerResponse and into fs.WriteStream with the former generating garbage (with some more bytes sent) and the latter resulting in valid output.
EDIT: This fix would be useful in LTS release, too.
I'd be happy to work on this issue this weekend.
I was looking at this, and can confirm there's "extra bytes" when piping a readable stream into e.g., a
ServerResponseandprocess.stdout(to @soletan's) comment.This seems to be because
Transfer-encoding: chunked(wiki) is set by default (for response codes other than 204 and 304, anyway).To avoid this you can use e.g.,
serverResponse.removeHeader('transfer-encoding').I can't reproduce a situation in which a
ReadableStreamcontaining aBufferpiped into aServerResponseinexplicably becomes a string.The headers are text, of course--and it's all the same stream--so I can only guess that whatever @shaunc is using may be confused by this?
If I'm right, then this issue should be closed, as
setDefaultEncoding()isn't the problem. @apapirovski what do you think?I have tried several times to make
OutgoingMessagea direct descendant ofStream.Writable. Unfortunately, doing so would cause a significant (X0%) degradation of throughput for HTTP servers. I don't think that's acceptable. We end up doing this because otherwise we would have double-buffering inOutgoingMessageand theSocket, which is costly.The solution is to implement all methods in
OutgoingMessage, or maybe create aWrappedWritableclass that is shared between HTTP, HTTP2 and possibly others. This seems a pretty common case.Definitely. Also, make the same amendment to the HTTP2 docs.
- added a commit that references this issue
on Aug 16, 2018 - added a commit that references this issue
on Aug 19, 2018 - added a commit that references this issue
on Sep 3, 2018 can this be closed, given #22305 is landed?
Closing as it appears this is resolved. Can reopen if it turns out that it's not.
The documentation of http.ServerResponse claims that it implements the interface of
stream.Writable, which includessetDefaultEncoding. However,ServerResponsedoes not implementsetDefaultEncoding.I'm passing a server response to another library, which pipes an archiver.zip to it. The binary data is interpreted as
utf8. I should be able to avoid this by setting the default encoding.