Both transports sent an empty string as the user modes in RPL_MYINFO. On the IRC listener that left an empty parameter in the middle of the line, so a client that splits on spaces read the channel modes as the user modes. The reply now lists o and w, the user modes the server supports. Both transports read them from one constant in internal/service, next to the code that decides which user modes MODE accepts. The README and the schema notes now show what the HTTP API sends. Model: opus-5-5
This commit was merged in pull request #237.
This commit is contained in:
+2
-2
@@ -144,8 +144,8 @@ Where a schema file and the HTTP API disagree, the HTTP API is right:
|
||||
with `ERR_NEEDMOREPARAMS` (`461`). A `body` of `[""]` clears the topic.
|
||||
- `003.json` describes the server's creation date. The HTTP API sends the date
|
||||
the server last started.
|
||||
- `004.json` has example mode lists. The HTTP API sends an empty string as the
|
||||
user modes and `ikmnostl` as the channel modes.
|
||||
- `004.json` has example mode lists. The HTTP API sends `ow` as the user modes
|
||||
and `ikmnostl` as the channel modes.
|
||||
- `322.json` says `LIST` gets one reply per channel. The server leaves out a
|
||||
secret channel, one with mode `+s`, unless the user is on it.
|
||||
- `332.json` says `RPL_TOPIC` answers a `TOPIC` query. The HTTP API has no such
|
||||
|
||||
Reference in New Issue
Block a user