Chrome/Edge not sending preflight OPTIONS requests cross origin while Firefox works

Question

I'm sending Authorization token in the header to both the same-origin and cross origin servers. I have set up the server to respond to OPTIONS requests with the following headers:

HTTP/1.1 204 No Content
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://10.26.97.22:10251 (this is dynamically set to the origin of the request)
Vary: Origin
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: authorization
Access-Control-Max-Age: 86400
Connection: keep-alive

The requests on Firefox work (the above is what's shown for Firefox's response header.) and the POST requests that triggered the preflight requests go through no problem.

However, neither Chrome nor Edge work with no error reported. Just failed requests saying net::ERR_RESPONSE_HEADERS_TRUNCATED.

Below is the success response to POST requests that actually go through on Firefox:

HTTP/1.1 200 OK
Connection: keep-alive
Date: Tue, 07 Nov 2023 00:05:49 GMT
Content-type: application/json
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://10.26.97.22:10251 (again, this is dynamically set)
Vary: Origin
Strict-Transport-Security: max-age=31536000
Referrer-Policy: no-referrer
Content-Security-Policy: default-src 'none'; font-src 'self' data:; script-src 'self'; connect-src *; img-src 'self'; style-src 'self';base-uri 'self';form-action 'self';
Cache-Control: no-cache

I tried clearing cache, opening the site in incognito mode, as well as start chrome with web security disabled. Only worked when web security is disabled.

I compared the preflight requst headers between regular Chrome and Firefox, see below:

Regular Chrome:

Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Access-Control-Request-Headers: authorization
Access-Control-Request-Method: POST
Connection: keep-alive
Host: 10.26.97.30:10261
Origin: https://10.26.97.22:10251
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36

Firefox:

OPTIONS /homepage HTTP/1.1
Host: 10.26.97.30:10261
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization
Origin: https://10.26.97.22:10251
DNT: 1
Sec-GPC: 1
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
Pragma: no-cache
Cache-Control: no-cache

Answer 1

Turns out, it might be happening because I didn't terminate the header properly. Even though I've indicated that the OPTIONS response has no content (HTTP/1.1 204 No Content), it still needs the extra empty line to terminate the header section. It seems like Firefox is a little bit more forgiving than Chromimum-based browsers. Added an empty line after the last header printout solved the issue.

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages