coolwsd does not support HTTP/2 CONNECT method used by modern Chrome for WebSocket connections

[Darshan-upadhyay1110]

Description: We’ve encountered a regression in document loading when accessing Collabora Online via Chrome. After thorough debugging by a user , it was identified that Chrome has changed how it initiates WebSocket connections: it now uses HTTP/2 with the CONNECT method, instead of HTTP/1.1 with the Upgrade: websocket header.

This breaks setups using reverse proxies like lighttpd, which are configured to route based on Upgrade headers. Since coolwsd currently does not support the CONNECT method, these requests return a 405 Method Not Allowed, causing document loading failures.

Observations:

• Firefox continues to work fine (uses HTTP/1.1 with Upgrade: websocket).
• Chrome fails with “Document loading failed”.
• Debug logs show Chrome initiating a CONNECT request over HTTP/2, which is not handled by coolwsd.

Steps to Reproduce:

1. Set up Collabora Online behind a reverse proxy (e.g., lighttpd or nginx).
2. Open a document in Firefox – it works.
3. Open the same document in Chrome – it fails with “Document loading failed”.
4. Observe a 405 response to an HTTP/2 CONNECT request in server logs.

Expected Behavior: coolwsd should support the WebSocket protocol when initiated using HTTP/2 CONNECT, as modern browsers are increasingly moving toward this method.

huge thanks to Bernd Wechner who reported and investigated this on the forum https://forum.collaboraonline.com/t/problem-with-http2-0-connect-requests-document-loading-failed/3777

[bernd-wechner]

For the record, a workaround in lighttpd that downgrades the proxy forward from HTTP2 CONNECT (with :protocol: websocket) to an HTTP 1 GET (with Upgrade: websocket and Connection: Upgrade) so coolwsd never ses the CONNECT and all is good, is to add:

proxy.header += ("force-http10" => "enable")

before forwarding to the Collabara server. In full context at our end:

$HTTP["host"] =~ "^office\." {
            # Collabora essentially has two types of communication both over the port it listens on
            # (9980). Websockets, that need the Upgrade header and Connection header set and static
            # files that don't. They provide detailed expamples for Apache and Nginx considering every
            # form of URL they want, but we can distil two categories easily enough.
            $REQUEST_HEADER["Upgrade"] == "websocket" {
                proxy.header += ( "upgrade" => "enable" )
                proxy.server = ( "" => ( ( "host" => ip_cloud, "port" => port_cool ) ) )
            } else $HTTP["request-method"] == "CONNECT" {
                proxy.header += ( "upgrade" => "enable" )
                proxy.header += ("force-http10" => "enable")
                proxy.server = ( "" => ( ( "host" => ip_cloud, "port" => port_cool ) ) )
            } else {
                proxy.server = ( "" => ( ( "host" => ip_cloud ) ) )
            }

and Collabora now serves on Chrome and Firefox Android which were fail cases returning 405 before.

[gstrauss]

lighttpd supports RFC8441 Bootstrapping WebSockets with HTTP/2 https://www.rfc-editor.org/rfc/rfc8441 lighttpd uses HTTP/1.1 to connect to backends. You should use proxy.header += ( "upgrade" => "enable" ) to enable lighttpd reverse proxying to send Upgrade: websocket to the backend, but you should not need proxy.header += ("force-http10" => "enable"), as @bernd-wechner noted in https://redmine.lighttpd.net/boards/2/topics/11953

[LuCu11]

Hi,

I seem to be affected by a related issue, but with a slightly different setup and browser combination.

Environment:

• OS: Debian (stable)
• Web server: Apache 2.4 with PHP-FPM (PHP 8.2)
• Application: Nextcloud with Collabora Online (embedded)
• Browsers: Firefox (latest), Chrome/Chromium (latest)

Symptoms:

• When the site is served over HTTP/2, opening documents (e.g. spreadsheets) via Collabora in Firefox fails or the document does not load correctly.
• When I force Apache to use HTTP/1.1 only (i.e. remove “h2” from all Protocols directives), opening the same documents in Firefox works again.
• Chrome/Chromium, on the other hand, works fine for me when HTTP/2 is enabled.

So in my case, the combination Firefox + Collabora Online + HTTP/2 is causing problems, while Firefox + HTTP/1.1 works and Chrome seems unaffected.

At the moment I really don’t want to:

• switch my main browser just to open documents, or
• permanently disable HTTP/2 for the whole server, or
• introduce an extra reverse proxy/vHost setup only for Collabora.

Could you please share what the current status of this HTTP/2/WebSocket/CONNECT-related work is, and whether there is any recommended configuration or upcoming fix that would allow Collabora Online to work reliably with Firefox without having to disable HTTP/2 globally?

If any additional logs or configuration snippets (Apache vHost, Nextcloud/Collabora versions, etc.) would be helpful, I’m happy to provide them.

I truly appreciate your efforts and the work on resolving this issue. Thanks so much for any updates or help you can provide.

[Darshan-upadhyay1110]

Hi @LuCu11

It’s low priority because we are usually behind a reverse proxy, which already shields us from the browser. At the moment we have very limited resources for this, and it doesn’t seem like a high-impact issue since the reverse proxy can always provide the security you need.

I will update here when this work starts. It’s complex and will require around two to three months of development and testing to make sure nothing in the product breaks.