fix: 'Close received after close' error

[williamkapke]

When a server initiates a WebSocket close(), the current implementation allows sending multiple Close frames. This manifests as clients receiving code=1006 (abnormal closure) close.
(a 'Close received after close' error in Chromium)

In WriteHalf::write_frame(), the conditional logic was:

if frame.opcode == OpCode::Close {
    self.closed = true;
} else if self.closed {
    return Err(WebSocketError::ConnectionClosed);
}

The else if only triggers for non-Close frames, so a second Close frame would still be sent.

The Fix:

Check closed state before checking opcode:

if self.closed {
    if frame.opcode == OpCode::Close {
        return Ok(()); // Already sent close, no-op
    }
    return Err(WebSocketError::ConnectionClosed);
}

I also included the call to stream.shutdown().await? (as in #72) after sending Close frame to properly close the TCP write-half (per RFC 6455).

Note:

In PR #72, it was mentioned that the tests were having trouble. They are passing for me with this change and I added additional tests for this bug.

Admittedly I used Claude to create the tests- I'm not a rust master (just being honest!)
... I hope this helps. I really need this to make it upstream- I have a lot personally riding on it (thousands of deployments in airports around the world).

Thanks & Happy Holidays.

Fixes denoland/deno#21642
Closes #72

[williamkapke]

I see stream.shutdown().await? has timing issues on other platforms. Reflecting on this, I don't think this is needed and it doesn't seem like putting it in the write_frame() method is correct anyhow.

Also, it seems crossbario/autobahn-testsuite:0.8.2 doesn't exist anymore so I set it to latest and now CI passes.

[joncomstock]

I’m following this issue and wanted to add support for merging this PR. It addresses a real-world problem where multiple Close frames can be emitted, which leads Chromium clients to report 1006 (abnormal closure).

The fix is very contained: after a Close is sent, additional Close frames become a no-op, while non-Close frames still error as before. No API or protocol changes beyond write_frame.

Tests cover the behavior, existing tests pass, and CI is green. This looks like a solid, low-risk fix worth landing.

[airPenetration]

Wouldn't allowing to send multiple close frames give you more control though?

[littledivy]

Looks good, thank you. I'll test this downstream in Deno and merge.

[littledivy]

Backported this fix and released 0.8.1