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.

Sign up for GitHub

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

mention reading RPL_WELCOME to get the assigned nick #146

Merged
merged 3 commits into from
Jan 7, 2022
Merged

mention reading RPL_WELCOME to get the assigned nick #146

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
fd578c1
mention reading RPL_WELCOME to get the assigned nick
slingamn Nov 28, 2021
5348e76
review fixes
slingamn Nov 28, 2021
bf372ad
move note about nick detection to connection registration section
slingamn Nov 29, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions _includes/modern-appendix.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -221,6 +221,8 @@ We do try to note numerics where this is the case with a message like *"The text

The first message sent after client registration, this message introduces the client to the network. The text used in the last param of this message varies wildly.

The first parameter of this message is the nickname assigned by the network to the client. Since it may differ from the nickname the client requested with the `NICK` command (due to, e.g. server policy restrictions on nicknames), the client SHOULD use this parameter to determine its effective nickname at the time of connection. (Subsequent nickname changes, client-initiated or not, will be communicated by the server using a [NICK message](#nick-message).)
DanielOaks marked this conversation as resolved.
Show resolved Hide resolved

Servers that implement spoofed hostmasks in any capacity SHOULD NOT include the extended (complete) hostmask in the last parameter of this reply, either for all clients or for those whose hostnames have been spoofed. This is because some clients try to extract the hostname from this final parameter of this message and resolve this hostname, in order to discover their 'local IP address'.

Clients MUST NOT try to extract the hostname from the final parameter of this message and then attempt to resolve this hostname. This method of operation WILL BREAK and will cause issues when the server returns a spoofed hostname.
Expand Down