Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sasl: spec recommendations breaks single roundtrip connection registration #536

Open
emersion opened this issue Mar 2, 2024 · 4 comments

Comments

@emersion
Copy link
Contributor

emersion commented Mar 2, 2024

Clients want to minimize the number of roundtrips used to connect to an IRC server, especially on flaky connections such as mobile phones/hotspots. To this end, some clients (including gamja, goguma) send multiple commands in a single burst without waiting for the server reply.

The following commands are sent in a single burst:

AUTHENTICATE PLAIN
AUTHENTICATE <base64>
CAP END

The spec says:

If the client completes registration (with CAP END, NICK, USER and any other necessary messages) while the SASL authentication is still in progress, the server SHOULD abort it and send a 906 numeric, then register the client without authentication.

Ref inspircd/inspircd#2086

@grawity
Copy link
Contributor

grawity commented Mar 2, 2024

A few years ago I wanted to specify an equivalent of IMAP's SASL-IR cap, which allows a single AUTHENTICATE <mech> <1st-response> command, but was shot down because "nobody would ever need that".

@emersion
Copy link
Contributor Author

emersion commented Mar 2, 2024

Ah, seems like you've had the same idea as #520. While this helps a bit, it still wouldn't prevent the server from processing the CAP END before the single AUTHENTICATE command completes.

@slingamn
Copy link
Contributor

slingamn commented Mar 3, 2024

I was not aware of this recommendation and would support deleting it.

@SadieCat
Copy link
Contributor

SadieCat commented Mar 4, 2024

I'd support weakening the SHOULD to a MAY for clients using sasl-3.2 which would keep compatibility for clients that expect sasl-3.1 behaviour.

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

No branches or pull requests

4 participants