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

Minor CHARSET RFC compliance issue #664

Open
brazilofmux opened this issue Mar 24, 2015 · 1 comment
Open

Minor CHARSET RFC compliance issue #664

brazilofmux opened this issue Mar 24, 2015 · 1 comment

Comments

@brazilofmux
Copy link
Owner

Original issue 662 created by brazilofmux on 2011-05-15T00:43:38.000Z:

What version of the server are you using? MUX 2.10.0.5 Alpha. (Test host: shangrila.mushpark.com:9999)

What steps will reproduce the problem?

  1. Connect to MUX server with a client that will respond positively to both [IAC WILL CHARSET] and [IAC DO CHARSET].
  2. Arrange for the client to send [IAC SB CHARSET REQUEST <> IAC SE] immediately after it replies to the server's [IAC DO CHARSET] with [IAC WILL CHARSET].

A log of this from my client's console, trimmed to only CHARSET related log lines, is below. The "Telnet Irregularity" line refers to the console log message beneath it. Note the order of the messages: first the client sends REQUEST, then the server sends REQUEST, then both reply. If the server replied to the client's REQUEST before sending its own, this issue would not apply; it would just be a renegotiation initiated by the server.

2011-05-14 18:16:55.444 Koan[30913:a0f] [shangrila.mushpark.com:9999] Received: IAC WILL CHARSET.
2011-05-14 18:16:55.445 Koan[30913:a0f] [shangrila.mushpark.com:9999] Sent: IAC DO CHARSET.
2011-05-14 18:16:55.445 Koan[30913:a0f] [shangrila.mushpark.com:9999] Received: IAC DO CHARSET.
2011-05-14 18:16:55.446 Koan[30913:a0f] [shangrila.mushpark.com:9999] Sent: IAC WILL CHARSET.
2011-05-14 18:16:55.446 Koan[30913:a0f] [shangrila.mushpark.com:9999] Sent: IAC SB CHARSET REQUEST <UTF-8 ISO-8859-1 US-ASCII> IAC SE.
2011-05-14 18:16:57.288 Koan[30913:a0f] [shangrila.mushpark.com:9999] Received: IAC SB CHARSET REQUEST <UTF-8 ISO-8859-1 ISO-8859-2 US-ASCII CP437> IAC SE.
2011-05-14 18:16:57.290 Koan[30913:a0f] [shangrila.mushpark.com:9999] Sent: IAC SB CHARSET ACCEPTED UTF-8 IAC SE.
2011-05-14 18:16:57.291 Koan[30913:a0f] [shangrila.mushpark.com:9999] Telnet irregularity: Received CHARSET ACCEPTED subnegotiation, but no active negotiation in progress.
2011-05-14 18:16:57.292 Koan[30913:a0f] [shangrila.mushpark.com:9999] Received: IAC SB CHARSET ACCEPTED UTF-8 IAC SE.

What is the expected output?
According to RFC2066 page 9 (quoted below) when a server and client simultaneously send [IAC SB CHARSET REQUEST <> IAC SE] stanzas, the server MUST reject the client's request, and the client MUST respond normally to the server's request.

What output do you see instead?
MUX replies to the client's request with [IAC SB CHARSET ACCEPTED <> IAC SE] rather than [IAC SB CHARSET REJECTED IAC SE].

Please provide any additional information below.
Quote from the relevant paragraph of RFC2066:

"In some cases, both the server and the client systems are able to perform translations and to send and receive in the character set(s) expected by the other side. In such cases, either side can request that the other use the character set it prefers. When both sides simultaneously make such a request (send CHARSET REQUEST messages), the server MUST reject the client's request by sending a CHARSET REJECTED message. The client system MUST respond to the server's request. (See the CHARSET REQUEST description, above.)"

It is unlikely that most clients will run into this issue, and the ones that do encounter it probably have robust enough telnet option handling that it won't cause a major problem - my client simply allows the invalid ACCEPTED as though it were valid, for example. This is a minor bug, but fixing it should have little to no impact on existing clients.

@brazilofmux
Copy link
Owner Author

Comment #1 originally posted by brazilofmux on 2011-05-16T07:04:03.000Z:

<empty>

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

1 participant