Micronaut unjustly refuses WebSocket connections from Firefox

[BenTels]

Thanks for reporting an issue, please review the task list below before submitting the
issue. Your issue report will be closed if the issue is incomplete and the below tasks not completed.

NOTE: If you are unsure about something and the issue is more of a question a better place to ask questions is on Stack Overflow (https://stackoverflow.com/tags/micronaut) or Gitter (https://gitter.im/micronautfw/). DO NOT use the issue tracker to ask questions.

Task List

• Steps to reproduce provided
• Stacktrace (if present) provided
• Example that reproduces the problem uploaded to Github
• Full description of the issue provided (see below)

Steps to Reproduce

1. Set up a web socket server in Micronaut
2. Connect to it with Firefox 78 or 88 (and probably versions in between as well), or simulate the Firefox request in curl
3. Watch the connection be refused

Expected Behaviour

The web socket session should be established

Actual Behaviour

The connection is refused as a 400 bad request and the error message is {"message":"Not a WebSocket request","_links":{"self":{"href":"/topics/person","templated":false}}}

Environment Information

• Operating System: Linux, kernel 5.3.18-lp152.75-preempt/ OpenSuSE LEAP 15.2
• Micronaut Version: 2.5.1 and 2.5.3
• JDK Version: 16.0.1
• Firefox version: 78.10.0esr (64-bit) and 88.0.1 (64-bit)

Description

Experimenting with curl, and comparing Firefox to Chrome, I think the problem is in the connection header. This is the curl simulation for Firefox:

curl --include
--no-buffer
--header "Host: localhost:8080"
--header "User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0"
--header "Accept: /"
--header "Accept-Language: en-US,en;q=0.5"
--header "Accept-Encoding: gzip, deflate"
--header "Sec-WebSocket-Version: 13"
--header "Origin: http://localhost:3000"
--header "Sec-WebSocket-Extensions: permessage-deflate"
--header "Sec-WebSocket-Key: CLHpIeywCglp4c7R+/LIfw=="
--header "Connection: keep-alive, Upgrade"
--header "Pragma: no-cache"
--header "Cache-Control: no-cache"
--header "Upgrade: websocket"
http://localhost.localdomain:8080/topics/person

Chrome does not send the keep-alive. Removing it from the curl simulation like so:

curl --include
--no-buffer
--header "Host: localhost:8080"
--header "User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0"
--header "Accept: /"
--header "Accept-Language: en-US,en;q=0.5"
--header "Accept-Encoding: gzip, deflate"
--header "Sec-WebSocket-Version: 13"
--header "Origin: http://localhost:3000"
--header "Sec-WebSocket-Extensions: permessage-deflate"
--header "Sec-WebSocket-Key: CLHpIeywCglp4c7R+/LIfw=="
--header "Connection: Upgrade"
--header "Pragma: no-cache"
--header "Cache-Control: no-cache"
--header "Upgrade: websocket"
http://localhost.localdomain:8080/topics/person

establishes the connection as expected. I suspect Micronaut is not taking into account that the Connect header is allowed to contain a list of values.

[dstepanov]

Looks like I broke it with 5f7a097

[jamesdh]

Related: https://gitter.im/micronautfw/questions?at=609fd4d59f2c352db10f5cc1

@dstepanov keep in mind that in my scenario, it's not that the websocket connection was being refused (I'm not using web sockets against Micronaut), it's that all connections were refused if the HTTP connection supported websockets.

Removing...

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

...from my nginx config fixed the issue for me.

I'd also add that this behavior started occurring from me when going from Micronaut 2.4.4 to 2.5.0.

[BenTels]

Guys,

I hate to be a pest, but this issue is not fixed. The root problem seems to be that Netty uses a header representation that represents headers as a single string even if a header is multi-valued.

I have created a pull request with a suggested fix (#5510 -- sorry if I did it wrong, this is all rather new to me). Please let me know if I f'ed it up and have to fix something.
Since Micronaut assumes Java 8 minimum, I assumed in my fix that using streams would be okay....

Best regards,

Ben.