Nit:

Optional suggestion: Change the comma to a period and make the Otherwise clause its own sentence.

I think this leaves one case undescribed: response.write(data); response.end(data)

Also, while accurate, so an improvement, I think its too low level, it doesn't give any idea why its done this way. And if you knew why, then you wouldn't need the docs.

I'd suggest that the .write() docs be modified to say that because .write() can be called multiple times, the size of the entire response (or request, I suspect these docs apply to both req and response) cannot be known when .write() is called, so HTTP will use chunked transfer encoding, and there will not be a content-size header.

In .end(), I'd say that if .write() has not previously been called, the total size is known (zero, or the size of the data arg), so node.js doesn't have to (and won't) use chunked transfer encoding, and it will write a content-length header. In other cases, since chunked transfer has already begun, any data provided to .end() will be transferred as a chunk.

^--- I think this is accurate, and describes why this is, and makes this seem less like a weird gotcha, and more like a feature: that if you have one large chunk that can be written in a single call to .end(), you can cause the content-size to be set and chunked mode not to be used. I'm not sure if it applies equally to the writing of requests, and the writing of responponses... but it should!

I only wanted to address the misleading sentence quoted in #26005 and not describe chunk mode. This is also not 100% accurate as the user could explicitly specify Content-Length disabling the default chunked mode. Perhaps it's simpler to just remove that sentence?

It would be nice to have the info about how explicitly setting the header changes things. Basically, that Node.js has good support for chunked mode (unlike a number of crappy HTTP APIs I've come across), is a wonderful feature, its a shame we don't document it better.

Your comment above makes me wonder if your proposed text is accurate/complete, doesn't it suffer the same problem?

For now, yes, I think rather than dumping in the detail you proposed, if you aren't up to a really comprehensive treatment, just changing "the same as" to "similar in effect to", or similar weasel words, might make the docs "not wrong", even though it still leaves streaming vs non-streaming mode undoced.

Your comment above makes me wonder if your proposed text is accurate/complete, doesn't it suffer the same problem?

Yes, I've added "the headers that are sent by default" to address that but I guess it's not clear.

I will change this tomorrow and use "similar" removing all the chunked mode info.
FWIW the request counterparts are slightly better documented.