Hello OpenLiteSpeed team,
I’d like to report a possible regression/edge-case in OpenLiteSpeed 1.8.5 related to HTTP/2 header handling.
After upgrading to OLS 1.8.5, some end users started getting in the browser:
ERR_HTTP2_PROTOCOL_ERROR (200 OK)
The request starts as 200 OK, but the connection/stream is abruptly closed and the page becomes blank. There are no PHP errors and no application-level errors logged. The same route works consistently if forced to HTTP/1.1.
A RunCloud engineer mentioned this might be related to the 1.8.5 changelog item:
“[Bug Fix] Address a HTTP/2 header handling corner case”
So we suspect a corner case in HTTP/2 header processing (or stream handling) introduced/affected in 1.8.5.
Environment
Web server: OpenLiteSpeed 1.8.5
Control panel: RunCloud
Reverse proxy: Cloudflare (WordPress site behind it)
App: WordPress (dynamic logged-in dashboard routes)
Production environment
Behavior / Symptoms
Only happens for some clients (not all), which makes it hard to reproduce consistently.
Appears only under HTTP/2 in the browser.
Forcing HTTP/1.1 removes the issue (200 OK consistently).
Cloudflare edge cache not involved (responses are dynamic).
Video reproduction
Here is a short video demonstrating the issue happening in the browser:
What we already tried
Verified that the same endpoint works via HTTP/1.1
Tested different compression/protocol combinations
HTTP/2 to origin disabled in Cloudflare (issue still manifests under HTTP/2 client-side)
No consistent pattern found in WordPress/PHP logs
Questions / What we need help with
Is there any known issue/regression in OLS 1.8.5 regarding HTTP/2 header handling that could cause a stream/connection to close after returning 200?
Any recommended debug flags/log settings to capture the exact reason for a HTTP/2 stream reset / protocol error?
If you suspect a specific header pattern, size limit, or invalid header state, I can capture and provide:
Response headers (sanitized)
HAR file / curl output
OLS debug logs around the request timestamp
Thank you for your time — I’m happy to provide any additional info to help reproduce.
Kind regards,
João
I’d like to report a possible regression/edge-case in OpenLiteSpeed 1.8.5 related to HTTP/2 header handling.
After upgrading to OLS 1.8.5, some end users started getting in the browser:
ERR_HTTP2_PROTOCOL_ERROR (200 OK)
The request starts as 200 OK, but the connection/stream is abruptly closed and the page becomes blank. There are no PHP errors and no application-level errors logged. The same route works consistently if forced to HTTP/1.1.
A RunCloud engineer mentioned this might be related to the 1.8.5 changelog item:
“[Bug Fix] Address a HTTP/2 header handling corner case”
So we suspect a corner case in HTTP/2 header processing (or stream handling) introduced/affected in 1.8.5.
Environment
Web server: OpenLiteSpeed 1.8.5
Control panel: RunCloud
Reverse proxy: Cloudflare (WordPress site behind it)
App: WordPress (dynamic logged-in dashboard routes)
Production environment
Behavior / Symptoms
Only happens for some clients (not all), which makes it hard to reproduce consistently.
Appears only under HTTP/2 in the browser.
Forcing HTTP/1.1 removes the issue (200 OK consistently).
Cloudflare edge cache not involved (responses are dynamic).
Video reproduction
Here is a short video demonstrating the issue happening in the browser:
What we already tried
Verified that the same endpoint works via HTTP/1.1
Tested different compression/protocol combinations
HTTP/2 to origin disabled in Cloudflare (issue still manifests under HTTP/2 client-side)
No consistent pattern found in WordPress/PHP logs
Questions / What we need help with
Is there any known issue/regression in OLS 1.8.5 regarding HTTP/2 header handling that could cause a stream/connection to close after returning 200?
Any recommended debug flags/log settings to capture the exact reason for a HTTP/2 stream reset / protocol error?
If you suspect a specific header pattern, size limit, or invalid header state, I can capture and provide:
Response headers (sanitized)
HAR file / curl output
OLS debug logs around the request timestamp
Thank you for your time — I’m happy to provide any additional info to help reproduce.
Kind regards,
João
