http: don't write error to socket

[ronag]

The state of the connection is unknown at this point and
writing to it can corrupt client state before it is aware
of an error.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[ronag]

Maybe a bit too strict but figuring out whether it's actually safe to write to the socket or not is non trivial.

[lpinca]

It's best effort, I don't think we should change this.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/32453/

[ronag]

It's best effort, I don't think we should change this.

Why? It can corrupt responses without the client being able to detect it?

[lpinca]

What is the advantage in removing the response? It's a single chunk which is written in a single write with no other pending writes.

[ronag]

It's a single chunk which is written in a single write with no other pending writes.

I haven't followed the code fully but I believe e.g. bad response could be written after the http headers are written and be parsed as part of the http response body.

In the case of 'upgrade' (websocket) and 'connect' I'm not sure what actually happens.

[ronag]

@nodejs/http

[lpinca]

On upgrade the parser is freed and the socketOnError listener removed. And if the client writes an invalid upgrade request a 400 response if expected.

[ronag]

On upgrade the parser is freed and the socketOnError listener removed. And if the client writes an invalid upgrade request a 400 response if expected.

Cool. That leaves the after headers are written scenario.

[dougwilson]

I don't have specific opinion to add to this PR, but just wanted to link the original PR #15324 that added the first response writing if any of the conversation from that thread helps here.

[lpinca]

Cool. That leaves the after headers are written scenario.

I do not remember any bug report opened for this scenario. Do you mean something like this?

• Part of the response is written when the request is in progress.
• The request triggers a 'clientError'.

[ronag]

Ok. Changed to only write if nothing else has been written to the socket.

[ronag]

Cool. That leaves the after headers are written scenario.

I do not remember any bug report opened for this scenario.

There is non as far as I know.

Do you mean something like this?

• Part of the response is written when the request is in progress.
• The request triggers a 'clientError'.

The socket emits 'error' at any point after the headers has been written and the body has not yet completed writing. Writes can still succeed after 'error' is emitted.

[lpinca]

Looks better now.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/32454/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/32456/

[mcollina]

lgtm

[wa-Nadoo]

I think the 'clientError' event documentation should be updated too https://nodejs.org/api/http.html#http_event_clienterror

[ronag]

@wa-Nadoo PTAL

[ronag]

Landed in e8d7fed

[MylesBorins]

This change is breaking a test on v14.x

=== release test-http-1.0 ===
Path: parallel/test-http-1.0
assert.js:103
throw new AssertionError(obj);
^
AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
+ actual - expected
+ ''
- 'HTTP/1.1 200 OK\r\n' +
- 'Content-Type: text/plain\r\n' +
- 'Connection: close\r\n' +
- 'Transfer-Encoding: chunked\r\n' +
- '\r\n' +
- '7\r\n' +
- 'Hello, \r\n' +
- '6\r\n' +
- 'world!\r\n' +
- '0\r\n' +
- '\r\n'
at response_validator (/Users/mylesborins/code/node/v14.x/test/parallel/test-http-1.0.js:158:12)
at Socket.<anonymous> (/Users/mylesborins/code/node/v14.x/test/parallel/test-http-1.0.js:54:7)
at Socket.<anonymous> (/Users/mylesborins/code/node/v14.x/test/common/index.js:363:15)
at Socket.emit (events.js:326:22)
at endReadableNT (_stream_readable.js:1244:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21) {
generatedMessage: true,
code: 'ERR_ASSERTION',
actual: '',
expected: 'HTTP/1.1 200 OK\r\n' +
'Content-Type: text/plain\r\n' +
'Connection: close\r\n' +
'Transfer-Encoding: chunked\r\n' +
'\r\n' +
'7\r\n' +
'Hello, \r\n' +
'6\r\n' +
'world!\r\n' +
'0\r\n' +
'\r\n',
operator: 'strictEqual'
}

Any idea what's going on? Should this be backported?