I found an issue in MaxLib.WebServer where HTTP request headers seem to be parsed incompletely when the header section becomes large.
Environment:
MaxLib.WebServer: 3.6.0
Deployment: Browser -> Cloudflare Proxy -> Nginx -> MaxLib.WebServer
Affected endpoint: WebSocket upgrade endpoint
Backend connection from Nginx to app: plain HTTP
Observed behavior:
When the request headers are short, everything works.
When headers are longer (for example with Cloudflare/proxy-related headers), the backend receives incomplete header lines.
In my logs, a header like Sec-Fetch-Mode: websocket appears truncated as Sec-Fetch-Mode: websock, followed by invalid trailing bytes.
The WebSocket handshake fails, and the client keeps reconnecting.
Expected behavior:
The request parser should read and buffer until the full HTTP header block is received, ending with CRLF CRLF, even if data arrives in multiple socket reads.
Header lines should never be partially parsed as complete lines.
Why this matters:
Proxy chains (especially with Cloudflare) can increase request header size significantly. This can break WebSocket upgrades in production even when the proxy config is valid.
Additional notes:
As a temporary workaround, reducing forwarded headers in Nginx helps reduce occurrence, but does not solve the root cause.
This looks like a parser/read-boundary issue rather than a proxy misconfiguration.
I found an issue in MaxLib.WebServer where HTTP request headers seem to be parsed incompletely when the header section becomes large.
Environment:
MaxLib.WebServer: 3.6.0
Deployment: Browser -> Cloudflare Proxy -> Nginx -> MaxLib.WebServer
Affected endpoint: WebSocket upgrade endpoint
Backend connection from Nginx to app: plain HTTP
Observed behavior:
When the request headers are short, everything works.
When headers are longer (for example with Cloudflare/proxy-related headers), the backend receives incomplete header lines.
In my logs, a header like Sec-Fetch-Mode: websocket appears truncated as Sec-Fetch-Mode: websock, followed by invalid trailing bytes.
The WebSocket handshake fails, and the client keeps reconnecting.
Expected behavior:
The request parser should read and buffer until the full HTTP header block is received, ending with CRLF CRLF, even if data arrives in multiple socket reads.
Header lines should never be partially parsed as complete lines.
Why this matters:
Proxy chains (especially with Cloudflare) can increase request header size significantly. This can break WebSocket upgrades in production even when the proxy config is valid.
Additional notes:
As a temporary workaround, reducing forwarded headers in Nginx helps reduce occurrence, but does not solve the root cause.
This looks like a parser/read-boundary issue rather than a proxy misconfiguration.