Skip to content

Conversation

@rizlik
Copy link
Contributor

@rizlik rizlik commented Nov 6, 2025

Server-side accept (TLS 1.3/DTLS 1.3) could lose the early-data shortcut whenever sending the Finished flight first hit WANT_WRITE. The buffered data advanced acceptState past TLS13_ACCEPT_FINISHED_SENT as soon as it flushed, so the next wolfSSL_accept() call skipped the block that marks SERVER_FINISHED_COMPLETE and lets the application drain 0-RTT data. By keeping the FALL_THROUGH into TLS13_ACCEPT_FINISHED_SENT and only returning early while that handshake flag is still unset, we revisit the shortcut immediately after the buffered flight is delivered, preserving the intentional behaviour even under non-blocking I/O.

On the client, the same pattern showed up after SendTls13ClientHello() buffered due to WANT_WRITE: after flushing, the connect state is already CLIENT_HELLO_SENT so the early-data exit is no longer executed. We now fall through into the CLIENT_HELLO_SENT case and only short-circuit once per handshake, ensuring the reply-processing loop still executes on the retry.

Testing still missing

Server-side accept (TLS 1.3/DTLS 1.3) could lose the early-data shortcut
whenever sending the Finished flight first hit WANT_WRITE. The buffered
data advanced acceptState past TLS13_ACCEPT_FINISHED_SENT as soon as it
flushed, so the next wolfSSL_accept() call skipped the block that marks
SERVER_FINISHED_COMPLETE and lets the application drain 0-RTT data. By
keeping the FALL_THROUGH into TLS13_ACCEPT_FINISHED_SENT and only
returning early while that handshake flag is still unset, we revisit the
shortcut immediately after the buffered flight is delivered, preserving
the intentional behaviour even under non-blocking I/O.

On the client, the same pattern showed up after SendTls13ClientHello()
buffered due to WANT_WRITE: after flushing, the connect state is already
CLIENT_HELLO_SENT so the early-data exit is no longer executed. We now
fall through into the CLIENT_HELLO_SENT case and only short-circuit once
per handshake, ensuring the reply-processing loop still executes on the
retry.
@rizlik
Copy link
Contributor Author

rizlik commented Nov 6, 2025

retest this please

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant