add a comment about websocket close test

[anonrig]

For web compliance... purposes...

[danlapid]

@jp4a50 is this what I think it is?

[codspeed-hq]

Merging this PR will degrade performance by 16.27%

❌ 1 regressed benchmark
✅ 69 untouched benchmarks
⏩ 129 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
❌	jsonResponse[Response]	40 µs	47.7 µs	-16.27%

---

_{Comparing yagiz/fix-websocket-closed (f5ce26a) with main (5080c86)}

Footnotes

1. 129 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[danlapid]

This seems like the wrong layer to solve this

[kentonv]

We intentionally don't send close messages automatically in reply to receiving a close because it breaks proxying. Imagine a worker which has two WebSocket connections open, A and B, and is proxying between them (forwarding all messages received on A to B and vice versa).

Now the worker receives a close message on A. It forwards the close message to B. It then needs to wait for B's reply close message, so it can then forward that to A.

If the system automatically sends a close reply to A immediately upon receiving a close message, this doesn't work right. This is why we didn't implement it that way.

With that said, you could make some valid arguments that we made the wrong choice here. Is it actually important that B get a chance to flush remaining messages and provide its own close message? Given that the WebSocket spec says that the reply close should happen automatically, perhaps it's the case that WebSocket close messages are not intended to be graceful, but rather intended to immediately terminate the connection. This isn't really "good networking theory" but maybe it's fine in practice and not worth it to deviate?

Maybe what we should really do is provide an explicit extension that lets people specify when they want to manually manage close messages? Like an allowHalfOpen sort of thing?

I could be convinced.