The changes in PR 41 introduced a regression whereby the read-ahead buffered input stream gets thrown away after the protocol has been detected but before the protocol negotiation starts.
The result of this is that depending on random timing factors, the capability and mode information that has been sent to the remote side may get lost and one side will infer a capability of 0 while the other side believes the agreed capability to be more.
When the remote side is assuming chunking, the connection will typically fail immediately with an error such as:
INFO: Protocol failed to establish channel
java.io.StreamCorruptedException: invalid stream header: 0A6CACED
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:806)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:299)
at hudson.remoting.ObjectInputStreamEx.<init>(ObjectInputStreamEx.java:48)
at hudson.remoting.ChannelBuilder.makeTransport(ChannelBuilder.java:430)
at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:389)
at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:310)
at org.jenkinsci.remoting.engine.JnlpProtocol2.buildChannel(JnlpProtocol2.java:93)
at org.jenkinsci.remoting.engine.JnlpProtocol.establishChannel(JnlpProtocol.java:79)
at hudson.remoting.Engine.run(Engine.java:245)
But if the remote side is not assuming chunking then more subtle remoting issues could arise (e.g. if the remote slave is running an older pre-chunking slave.jar and connecting to a newer Jenkins... not that you should be doing that, but some people may... this reason is why I argue the issue is "Critical")
Bug
Critical
JENKINS-26580 For JNLP slaves the master-slave communication should be encrypted
