View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006630 | unreal | ircd | public | 2026-06-21 19:24 | 2026-06-21 20:03 |
| Reporter | progval | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Summary | 0006630: CAP LS * reply is sent to non-302 clients | ||||
| Description | The "CAP LS *" syntax, which allows sending more than one line of capabilities, is an extension of the capability negotiation version 302: https://ircv3.net/specs/extensions/capability-negotiation#cap-ls-version-features But with recent additions to the list of capabilities (coincidentally "draft/multiline", which is unrelated to multi-line CAP LS), Unreal's response to "CAP LS" that are not "CAP LS 302" no longer fits on a single line, causing Unreal to violate the spec: The solution to this is to omit some capabilities to clients that don't support version 302. I guess Unreal (or its modules) could hardcode a set of "old" capabilities, as clients not supporting version 302 are unlikely to support recent and complex specs like multiline, chathistory, labeled-response, or metadata. | ||||
| Steps To Reproduce | With latest commit (UnrealIRCd-6.2.6-rc1): 1782036556.641 bar -> S: CAP LS 1782036556.641 bar -> S: NICK bar 1782036556.641 bar -> S: USER u s e r 1782036556.641 bar -> S: CAP END 1782036556.641 S -> bar: :My.Little.Server CAP * LS * :unrealircd.org/link-security unrealircd.org/plaintext-policy unrealircd.org/history-storage draft/metadata-notify-2 draft/metadata-2 away-notify invite-notify extended-join userhost-in-names multi-prefix cap-notify setname tls chghost account-notify message-tags batch server-time account-tag echo-message labeled-response draft/chathistory extended-monitor standard-replies no-implicit-names draft/no-implicit-names draft/extended-isupport draft/multiline 1782036556.641 S -> bar: :My.Little.Server CAP * LS :unrealircd.org/json-log | ||||
| 3rd party modules | |||||
|
|
Have to say my first instinct is like jesus.. CAP 302 is almost 9 years old!!! :D But, yeah, I will do something along the lines what you suggested, i will take care of it, thanks for the suggestion. Like I can scratch 3 for sure, like the informative ones that are useless without value anyway (so less-than-302)... you know, link security, plaintext policy, and a 3rd one i now forgot. But will probably do it the other way around: have some marked as "always advertise these because less-than-302 may need these" ProgVal: Do you know of any major clients that don't support 302? I hope it is very marginal? Just checking... it may influence what caps i enable for the "less-than-302 too" :) EDIT: Oh and I may do a more quick-hack-fix for 6.2.6 since it is already in rc1 stage, do a more proper fix later, but this aside |
|
|
According to https://ircv3.net/software/clients there is a bunch, including popular and/or maintained clients, primarily KVirc |
