std/http: close connection on .respond() error

[kevinkassimo]

Previously we did not handle automatic connection closing on .respond() error. This leaves the supposedly dead connection not closed (CLOSE_WAIT) (since req.done is never resolved due to error), resulting in errors like Too many files open. (which might be the cause of #3463 (comment))

A simple demonstration of what this patch fixes is with the following:

import { serve } from 'https://deno.land/std/http/server.ts';
const body = new TextEncoder().encode("Hello World\n");
const s = serve({ port: 8000 });

console.log("Listening on port 8000");

setInterval(() => {
  console.log(Object.keys(Deno.resources()).length);
}, 10000);

for await (const req of s) {
  req.respond({ body }).catch(() => {});
}

If you fire a few autocannon -c 100 -d 5 -p 10 https://localhost:8000 to this, you'll notice that Object.keys(Deno.resources()).length keeps growing. (likely due to autocannon closing conn on its side thus making .respond() fail (especially under pipelining))

With this patch, Object.keys(Deno.resources()).length should eventually return to a fixed amount.

[kevinkassimo]

Seems windows behaves slightly differently here?

[zhmushan]

Seems to be waiting for the next req (on my machine)

[kevinkassimo]

Yeah that should be the reason. I wonder why the second req.respond() does not fail on windows...

[kevinkassimo]

I'm thinking about probably skipping the added test for now on Windows, since the original behavior is indeed incorrect, and this change does not break other existing tests... (I don't have a Windows platform for me to experiment on...)

[ry]

Kevin - yes that sounds good .. please leave a Todo comment explaining the situation

[ry]

LGTM - thanks Kevin!