[tck] httpupgradehandler does not make sure that a `HttpUpgradeHandler` can be initialized properly

[laeubi]

Challenged tests
https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/src/main/java/servlet/tck/api/jakarta_servlet_http/httpupgradehandler/HttpUpgradeHandlerTests.java

TCK Version
Jakarta Servlet 6+

Description
The spec says:

When an upgrade request is received, the servlet can invoke the HttpServletRequest.upgrade method, which starts the upgrade process. This method instantiates the given HttpUpgradeHandler class. The returned HttpUpgradeHandler instance may be further customized.
After exiting the service method of the servlet, the servlet container completes the processing of all filters and marks the connection to be handled by the HttpUpgradeHandler. It then calls the HttpUpgradeHandler's init method, passing a WebConnection to allow the protocol handler access to the data streams.

This part of the specification is not correctly covered by the given TCK test:

In the TCKHttpUpgradeHandler the field delimiter is default initialized to the value /

servlet/tck/tck-runtime/src/main/java/servlet/tck/api/jakarta_servlet_http/httpupgradehandler/TCKHttpUpgradeHandler.java

Line 29 in 4e6a0b4

private String delimiter = "/";

in the TestServlet the delimiter is set to the value /

servlet/tck/tck-runtime/src/main/java/servlet/tck/api/jakarta_servlet_http/httpupgradehandler/TestServlet.java

Line 42 in 4e6a0b4

handler.setDelimiter("/");

So there is literally no way for the value to be any different than / at any time that can be observed from outside.

A much better way would be:

• Let the value keep the default without implicit initialization (resulting in null being the value at construction time)
• Let TCKReadListener use Objects.requireNonNull(delimiter) in the constructor to fail if the value failed to be initialized by TestServlet
• Furthermore TCKReadListener should have a method that returns the used delimiter
• TCKHttpUpgradeHandler#getDelimiter should return the delimiter from TCKReadListener and assert it is non null.

That way the TCK would make sure:

1. Instances of a HttpUpgradeHandler can be initialized
2. init(WebConnection wc) is not called to early or called never

Additional context
I noticed this here while testing the Jetty Implementation that passes the TCK:

• Servlet Upgrade Support is too eager jetty/jetty.project#13335 (comment)

[joakime]

I also added another TCK improvement.

• TCK should have additional tests for httpupgradehandler to ensure that Filters are processed after calling upgrade() #900

[markt-asf]

Successful challenges normally result in tests being excluded. If I am reading this correctly, the issue is that a specification non-compliant server can still pass the TCK. That would mean there is no need to exclude the test and therefore no need for a formal challenge.

I agree this is a bug, it should be fixed and - ideally - the fix back-ported. We only have the ability to do that for fix 6.2 and 6.1.

The proposed solution looks reaaonable to me. A PR that implemented that would be very much appreciated.

[joakime]

Agreed, this is a faulty TCK test that doesn't test what it says it does due to a bug in the TCK.

That bug allows non-compliant servers to pass the TCK.

[laeubi]

@joakime as you already added a new test would you mind fixing the existing test? I'm not really familiar with the testsuite and codebase and did the analysis only on a higher level code-review.
I could of course try to fix that but it seems maybe done faster and better by someone already familiar with the code base.

[omatheusmesmo]

Hello, I have submitted a pull request to address this issue.

[laeubi]

Many thanks for fixing this 👍