This "issue" is back again, a current master build WARN log entry

The change in this PR should make the exception message more descriptive: https://github.com/igniterealtime/Openfire/pull/461

What the RFC is not clear on is what the initiating party should do in both instances. Where the receiving party is closing the socket without sending data, it's probably best to not send data as the initiating party either?

I am experimenting with a fix in this pull request: https://github.com/igniterealtime/Openfire/pull/439/

So, according to RFC6120, there is a significant difference between:

• section 5.4.2.2 Failure Case, such as malformed commands and internal server errors.

• section 5.4.3.2 STARTTLS Failure, which includes TLS errors such as bad_certificate or handshake_failure.

There is an important difference in how the receiving entity should respond. section 5.4.2.2 Failure Case states:

MUST return a <failure/> element (...) close the XML stream, and terminate the underlying TCP connection.

On the other hand, section 5.4.3.2 STARTTLS Failure reads:

MUST terminate the TCP connection (...) MUST NOT send a closing </stream> tag before terminating the TCP connection

I don't believe that Openfire makes a distinction between Failure Case and STARTTLS Failure: STARTTLS is assumed successful, unless an exception is thrown. Handling of both cases is probably similar in each implementation (S2S and C2S have different implementation) - from what I gather (in SocketReadingMode.java), Openfire always sends a <failure/> element.

Is the root cause of this issue the lack of distinct handling of both cases?