Zowe APIML v3 bad error response compared to APIML v2 on Websocket connection attempt

[cumarav]

Describe the bug
If I am trying to connect to websocket in APIML V2 with invalid JWT token and see clear error message:

 The close message is Some(CloseData { status_code: 1003, reason: "org.eclipse.jetty.websocket.api.UpgradeException: Failed to upgrade to websocket: Unexpected HTTP Response Status Code: Invalid login credentials" }

If I do the same with APIML V3 reply:

 The close message is Some(CloseData { status_code: 1011, reason: null}

Steps to Reproduce

1. Try to connect with valid token - connection established.
2. Try to open websocket connection using invalid JWT Token - error message is not clear...

Expected behavior
I want to see the same 1003 error code and error message if websocket fails to open connection due to invalid JWT token in APIML V3.

Screenshots

Ass you see above - V3 always respond with 1011, empty reason whereas V2 gives specific code and correct reason for every case.

Impact
We have Integration Tests in CICD pipeline which verify invalid login behavior and consequently we not able to use APIML V3 in CICD pipeline because of this V2- V3 discrepancy

Logs

DEBUG websocat::ws_peer] The close message is Some(CloseData { status_code: 1011, reason: "" })

Willingness to help
If management approve....

[cumarav]

One more sreenshoot:

Here as you see word Bearer changes reason

[balhar-jakub]

@cumarav The status code was changed to the proper 1003 but we can't add the further details, the security requirements are gradually strengthening and thus we are allowed to expose less and less information especially around authentication and authorization.

I will mark the change in the message among the actual breaking changes, in case somebody else is expecting the message.

[pablocarle]

The change in V3 to use Spring Cloud Gateway's websocket implementation brings in additional checks in the services' responses.
In this case, the 401 HTTP status that the service replies makes SCG fail on a validation for https://www.rfc-editor.org/rfc/rfc7235#section-3.1
Which states that the services MUST reply with a WWW-Authenticate header.

The code will continue to be 1011 (generic server error), but with an improved message to include the description of the issue, in this case, the lack of WWW-Authenticate header.