TCK: HttpUpgradeHandler test incorrectly assumes reading of buffered POST data about servlet

[markt-asf]

Given the lack of further response combined with the current behaviour being aligned with the RFCs, I am closing this one.

[markt-asf]

TL;DR For Servlet <= 6.0, this is an Open Liberty bug that needs to be fixed, not a TCK bug. There is an option to change the Servlet specifcation for Servlet >= 6.1

The Servlet specification, correctly, makes no statement regarding the timing of sending data for the upgraded connection with respect to the HTTP 101 response.

It is RFC compliant to send data for an upgraded connection prior to receiving the HTTP 101 response. Quoting RFC 9110

A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e., the client can't change the protocol it is sending in the middle of a message).

Nothing in the current RFCs require the client to wait for the upgrade to be confirmed before using the protocol.

A number of RFCs for upgraded protocols do require the client to wait for the upgrade to be confirmed but those are protocol specific requirements, not generic upgrade requirements.

There is a general concern that optimistic upgrade (sending data using the upgraded protocol before the server has confirmed the upgrade) is problematic and there is an RFC in draft that would explicitly require all future upgrade protocols to protect against the security risks associated with optimistic upgrade. However, that RFC does not modify the language in RFC 9110 and optimistic upgrade remains specification compliant.

The TCK test could be improved to send the upgrade request and the data for the upgrade protocol at the same time which would result in a consistent TCK failure for Open Liberty and any similarly implemented servers.

We could modify the Servlet specification to reject any attempt at optimistic upgrade with a 400 response. I'm reluctant to do this as there are scenarios (which are the most likely use cases for a custom HttpUpgradeHandler) where optimistic upgrade is safe and it provides a performance improvement.

[brideck]

Thanks, Mark. I've passed this back to web dev for rebuttal/acquiescence.