http2: make compat finished match http/1

[ronag]

Looking at the http1 semantic the current http2 compat implementation of finished seems rather complicated and fragile? Also it doesn't match the semantics of http1.

I have one http2 compat test failing which I don't quite undertand the purpose of. Am I missing something critical here?

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

Refs: #24743

NOTE TO SELF: review cb behaviour when ending and destroyed. Is ´onStreamCloseResponse` required?

[ronag]

The interesting part here is that in http1 finished doesn't seem to care whether the socket is closed or not, it only cares about whether end has been called or not. While in http2-compat it doesn't really care that much about end, instead if mostly cares about whether the socket is closed or not.

I think this discrepancy is also missing a test somewhere? @mcollina

EDIT: See, fab97ee

[mcollina]

@jasnell can you help here?

[mcollina]

The interesting part here is that in http1 finished doesn't seem to care whether the socket is closed or not, it only cares about whether end has been called or not. While in http2-compat it doesn't really care that much about end, instead if mostly cares about whether the socket is closed or not.

I think this discrepancy is also missing a test somewhere? @mcollina

I think this is just a difference that we need to fix.

[ronag]

I'm actually a bit unsure what happens if you call end on a closed connection in http1?

[mcollina]

Can you please add a unit test that shows what you are trying to achieve?

[mcollina]

I'm actually a bit unsure what happens if you call end on a closed connection in http1?

if the stream is finished, nothing happens on multiple end() in HTTP1

node/lib/_http_outgoing.js

Lines 683 to 684 in b32c5f0

	if(this.finished){
	returnthis;

.

If you are still unsure, have you trying preparing an example?

[ronag]

@mcollina

if the stream is finished, nothing happens on multiple end() in HTTP1

This is if you have called end() previously. But what if you call end for the first time after the socket has aborted.

[mcollina]

Can you create an example to check this?

[jasnell]

Sorry @mcollina, I just spotted the notification on this. I'll queue this one up and take a look hopefully later today.

[apapirovski]

I'm sorry, but this is completely incorrect. There's a good reason that this makes a test fail.

[ronag]

@apapirovski care to expand on that?

The failing test looks wrong for me:

constserver=createServer(mustCall((request,response)=>{strictEqual(response.finished,true);response.writeHead(HTTP_STATUS_OK,{foo: 'bar'});response.end('data',mustCall());}));

It test that respone.finished is truebeforeend() is called which is not how http/1 behaves.

[apapirovski]

review cb behaviour when ending and destroyed. Is ´onStreamCloseResponse` required?

Yup, it is. We need to trigger those events in the HEAD case, as well as cleanup the proxy socket and other junk since otherwise they're mutually referencing each other and could cause memory leaks.

[ronag]

@Trott: CI

[nodejs-github-bot]

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

[ronag]

Would this be a bug fix or semver-major?

[ronag]

@Trott: CI failed due to merge conflict. Please try again.

[jasnell]

LGTM as a bug fix

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[ronag]

@nodejs/build I seem to be having problems with node-test-binary-arm-12+ in multiple PR's. Even those that just touch docs? #31805

[rvagg]

Thanks @ronag, don't treat this as a blocker for your code, it's a Jenkins problem on our end.

@nodejs/build we're having a commit-ref propagation problem, in https://ci.nodejs.org/job/node-test-pull-request/29176/:

• https://ci.nodejs.org/job/node-cross-compile/27729/nodes=cross-compiler-armv7-gcc-6/console creates jenkins-node-test-commit-arm-fanned-e6a54b67290f8bab3de5b88504e531c20271f1aa-binary-pi1p/cc-armv7
• https://ci.nodejs.org/job/git-nodesource-update-reference/23898/console syncs jenkins-node-test-commit-arm-fanned-e6a54b67290f8bab3de5b88504e531c20271f1aa-binary-pi1p/cc-armv7 👍
• https://ci.nodejs.org/job/node-test-binary-arm-12+/4402/RUN_SUBSET=0,label=pi3-docker/console tries to pull jenkins-node-test-commit-arm-fanned-db24c2588175371c1ec2ec767541583ddf7fa0b1-binary-pi1p/cc-armv7 👎

anyone got time to look at this one? @joaocgreis I bet you'd have the most insight and could see the problem quickest if you're available.

[ronag]

CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2272/ (queued)

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/29218/ ✔️

[joaocgreis]

Please do not use the "Resume build" when the PR changes. The "Resume build" only starts jobs that failed, so jobs that passed before will remain green, even if they would fail with the new changes. The "Resume build" feature is a source of problems, but it's the only way we have to reduce the impact of infra failures.

Please use "Rebuild" instead when there are any changes in the PR.

Both e6a54b6 and db24c25 were the head of #31805 at some point. Only the node-test-binary-arm-12+ job was started in https://ci.nodejs.org/job/node-test-pull-request/29176/. The other two were re-used from a previous PR because they passed, so the compile job never ran for the latest head.

[ronag]

Landed in 8ba7a2f