Open mrryanjohnston opened 1 week ago
That wording is inherited from RFC 2812 and seems slightly confused. Clients sending PASS
between NICK
and USER
should be discouraged but its not inherently wrong. As a server you should probably accept this unless there's something preventing you from doing so.
@SadieCat thanks!
I'm happy to make this a separate issue if necessary, but I have another question related to clarifying intended behavior of the server during the registration process.
The PASS message section says:
It is possible to send multiple PASS commands before registering but only the last one sent is used for verification and it may not be changed once the client has been registered
The USER message section does not specify what the server should do when the user sends multiple USER messages before registration is complete. Should the server discard the values sent with the first USER message in favor of the values sent in the second?
I think it's fair to leave this as an implementation choice
@progval Thanks!
The USER message section does not specify what the server should do when the user sends multiple USER messages before registration is complete. Should the server discard the values sent with the first USER message in favor of the values sent in the second?
The server should probably handle this because the server may respond with an error if the information in the first request isn't valid (e.g. ERR_INVALIDUSERNAME
) so it needs to be able to handle the client resending when that happens.
@SadieCat It makes sense to me that the server should handle the case where the client sends USER twice if the first message resulted in an ERR_INVALIDUSERNAME
. My curiosity was around the case when the first and second USER message was valid.
I appreciate the two of you for sating my curiosity so far. I've got another one: is there a "too many arguments" version of ERR_NEEDMOREPARAMS? The behavior I have noticed in other IRC servers is to discard "extra" parameters but not to inform the client.
That's correct, extra arguments are always ignored by existing implementations, as far as I know. But also not a requirement for new implementations.
@progval thanks. Checking my understanding: If I were to notify the user about the dropped params, I think what I might do is send a WARN
as per https://ircv3.net/specs/extensions/standard-replies
It looks like there is only 1 WARN
in the registry, and the parameter-related FAIL
messages account for INVALID_PARAMS
and the previous NEED_MORE_PARAMS
. If I understand the spec correctly, I should be able to send back a message that looks like this:
WARN MODE DISCARDED_PARAMS :You sent extra parameters which the server discarded
and the client would display it appropriately. Is my understanding correct?
That's correct, just make sure to check for the capability first.
@progval Thanks!
Thank you so much for this valuable resource.
The docs state:
What should servers do if they receive a NICK then a PASS before receiving the USER? Technically, the registration is not complete, and the NICK / USER combination have not yet been received. Has the client technically sent the PASS command before sending the NICK / USER combo?