[Bug] PerformHttpRequest silently drops the response body (and headers) above ~10 MB

[Pedro-Lucas14]

Summary

1. On the Enhanced server binary (cfx-server.exe), PerformHttpRequest invokes its callback with status = 200 but data = nil and no headers table whenever the HTTP response is larger than roughly 10 MB. Responses at 8 MB and below arrive intact.
2. errorData is empty and nothing is written to the console, so a resource cannot distinguish this from a legitimately empty response. The failure is completely silent.
3. The identical request against the identical endpoint returns the full body on the legacy FXServer.exe binary, at every size tested up to 32 MB — so this is a regression, not a long-standing limit.

Issue type

Server

Repro rate

Always

Server build version

FXServer-early-access b92 win32

OS

No response

CPU

No response

GPU

No response

RAM

No response

Storage type

None

Connection type

None

ISP and bandwidth

No response

DxDiag

No response

Network graph

No response

Platform

Windows

OS version / distribution

Windows Server 2022

CPU

AMD Ryzen 9

RAM

128 GB DDR4

Using txAdmin?

No

Hosting provider

Self-hosted

Machine type

Dedicated

/perf endpoint output

Not relevant to this repro — it is a single loopback HTTP request on an otherwise idle
server, and it fails identically on a freshly started server with only the repro resource
loaded. No DDoS protection or rate limiting sits between the two processes; both run on
the same host over 127.0.0.1.

DDoS protection

No response

ulimit -n value (Linux only)

No response

Docker Compose file (Docker only)

No response

Steps to Reproduce

1. Save the two files below into a resource folder named httpsize_repro.
2. Start the payload server: node payload-server.js (Node core http only, no npm install).
3. ensure httpsize_repro
4. Run httpsizetest in the server console.

payload-server.js — answers GET /<megabytes> with exactly that many megabytes and an accurate Content-Length:

const http = require('http')

http.createServer((req, res) => {
  const mb = Number((req.url.match(/(\d+)/) || [])[1]) || 1
  const body = Buffer.alloc(mb * 1024 * 1024, 0x41)
  res.writeHead(200, { 'Content-Type': 'text/plain', 'Content-Length': body.length })
  res.end(body)
}).listen(8899, '127.0.0.1', () => console.log('payload server on 127.0.0.1:8899'))

server.lua:

local SIZES_MB = { 1, 2, 4, 6, 8, 10, 12, 16, 20, 24, 32 }

RegisterCommand('httpsizetest', function()
    CreateThread(function()
        for _, mb in ipairs(SIZES_MB) do
            local p = promise.new()
            PerformHttpRequest(('http://127.0.0.1:8899/%d'):format(mb), function(status, data, headers, errorData)
                p:resolve({
                    status   = status,
                    received = data and #data or -1,
                    length   = type(headers) == 'table' and (headers['Content-Length'] or headers['content-length']) or nil,
                    err      = errorData,
                })
            end, 'GET')

            local r = Citizen.Await(p)
            local expected = mb * 1024 * 1024
            print(('%2d MB | status=%s | Content-Length=%s | received=%d | errorData=%s | %s'):format(
                mb, tostring(r.status), tostring(r.length), r.received, tostring(r.err),
                r.received == expected and 'OK' or 'MISMATCH'))

            Wait(250)
        end
    end)
end, true)

fxmanifest.lua is just fx_version 'cerulean', game 'common', server_script 'server.lua'.

Expected Behavior

The callback receives the complete body, matching the advertised Content-Length, as it
does on the legacy binary at all sizes up to 32 MB.

If a response-size cap is intentional on the new binary, the failure should surface as an
error status, a non-empty errorData, or at minimum a console warning — not as a
successful-looking 200 with nil data.

Actual Behavior

Above ~10 MB the callback fires with status = 200, data = nil, and no headers table.
errorData is empty. Nothing is logged.

Actual Behavior

Above ~10 MB the callback fires with status = 200, data = nil, and no headers table.
errorData is empty. Nothing is logged.

Evidence

Enhanced binary (cfx-server.exe) — fails from 10 MB on:

 size |  status | Content-Length |     received |      time | result
------+---------+----------------+--------------+-----------+--------
  1 MB |     200 |        1048576 |      1048576 |     153ms | OK
  2 MB |     200 |        2097152 |      2097152 |      43ms | OK
  4 MB |     200 |        4194304 |      4194304 |      64ms | OK
  6 MB |     200 |        6291456 |      6291456 |      86ms | OK
  8 MB |     200 |        8388608 |      8388608 |     106ms | OK
 10 MB |     200 |            nil |           -1 |      20ms | MISMATCH
 12 MB |     200 |            nil |           -1 |      20ms | MISMATCH
 16 MB |     200 |            nil |           -1 |      20ms | MISMATCH
 20 MB |     200 |            nil |           -1 |      20ms | MISMATCH
 24 MB |     200 |            nil |           -1 |      20ms | MISMATCH
 32 MB |     200 |            nil |           -1 |      20ms | MISMATCH

Legacy binary (FXServer.exe), same machine, same payload server — all sizes intact:

 size |  status | Content-Length |     received |      time | result
------+---------+----------------+--------------+-----------+--------
  1 MB |     200 |        1048576 |      1048576 |      51ms | OK
  2 MB |     200 |        2097152 |      2097152 |      51ms | OK
  4 MB |     200 |        4194304 |      4194304 |      51ms | OK
  6 MB |     200 |        6291456 |      6291456 |      51ms | OK
  8 MB |     200 |        8388608 |      8388608 |      54ms | OK
 10 MB |     200 |       10485760 |     10485760 |      53ms | OK
 12 MB |     200 |       12582912 |     12582912 |      54ms | OK
 16 MB |     200 |       16777216 |     16777216 |      56ms | OK
 20 MB |     200 |       20971520 |     20971520 |     107ms | OK
 24 MB |     200 |       25165824 |     25165824 |     107ms | OK
 32 MB |     200 |       33554432 |     33554432 |     114ms | OK

Exact cut-off, bisected byte by byte on the Enhanced binary:

TODO: paste the "httpsizefind" output

Independent confirmation that the payload server itself is fine — same endpoint, same
sizes, fetched with PowerShell on the same machine:

 1 MB -> status=200 bytes=1.048.576  expected=1.048.576  OK (75ms)
 8 MB -> status=200 bytes=8.388.608  expected=8.388.608  OK (107ms)
24 MB -> status=200 bytes=25.165.824 expected=25.165.824 OK (303ms)

Additional Context

Two things worth noting for whoever picks this up:

• Failing requests return faster than succeeding ones — ~20 ms versus ~106 ms for the
  8 MB success. The transfer looks aborted as soon as the limit is crossed, rather than
  read to completion and then discarded.
• The entire headers table is lost, not just the body. Content-Length comes back
  nil on the failing sizes, so the callback cannot even inspect what it was supposed to
  receive.

Response size is the only trigger we could find. We ruled out name resolution by running
the same sweep against both http://127.0.0.1:8899/ and http://localhost:8899/ — both
fail at exactly the same threshold.

Real-world impact for us: our framework loads its startup caches over HTTP from a local
database proxy. Two of those responses are 24.7 MB and 11.6 MB, and both came back empty
on the new binary, so the identifier cache never populated and no player could
authenticate — with no error anywhere to explain why. We have worked around it by
paginating those queries into ~1.4 MB chunks, but any resource fetching a large payload
over HTTP will hit this and get no diagnostic at all.

[FabianTerhorst]

Thanks, we are looking into this.

[Gogsi]

A fix for this bug has been implemented and is available in the latest patch. Please try again and let us know if the issue persists. Thanks for your help!

[Pedro-Lucas14]

Thank you, it's fixed now.