Call of Duty fast download: sv_pure, sv_allowDownload and HTTP redirect

Getting custom maps and mods onto clients is the part of CoD server administration with the most folklore attached to it. This page is the behaviour as it actually is, per engine generation.

The two cvars

sv_allowDownload controls whether the server will push a missing pak to a client at all. sv_pure controls whether the server audits the paks a client has loaded.

They are frequently described as if one implies the other. They do not.

The sv_pure x sv_allowDownload matrix

sv_pure is an audit, not a content filter. It does not reliably stop a client from loading its own paks. What it actually does is the referenced-pak checksum audit, dropping mismatched clients with EXE_UNPURECLIENTDETECTED.

The CoD1 1.1 pure-poison bug

On Call of Duty 1 patch 1.1 specifically, the client never resets its pure checksum state at connect time — only on a full filesystem shutdown. The practical consequence is that a 1.1 client carrying any mod pak from any previous server is dropped by every sv_pure 1 server it subsequently joins.

1.5 resets the state at connect, so it is unaffected.

This is why roughly 99% of surviving CoD1 1.1 servers run sv_pure 0 while the 1.5 scene runs sv_pure 1. It is not superstition, it is a real engine bug. On 1.1, use sv_pure 0.

UDP download: slow but universal

With sv_allowDownload 1 and nothing else, the engine streams the pak inside the game protocol. It works everywhere and it is slow: roughly 5–10 KB/s on CoD1, because the default block size is 2 KB and blocks are acknowledged serially.

A 40 MB map pack over that path is a ten-minute join. Players do not wait ten minutes.

On CoD1 1.1 with CodExtended, sv_fastDownload 1 raises the block size from 2 KB to 8 KB, roughly a 4x improvement. It is still UDP and still slow compared to HTTP.

Clients must opt in

CoD1 1.1's client defaults to cl_allowDownload "0", so an out-of-the-box client refuses downloads regardless of your server settings.

CodExtended solves this by registering cl_allowDownload as CVAR_SYSTEMINFO. When the server sets it, the value lands in the systeminfo configstring, the client applies it to its local copy, and the download predicate passes:

set sv_pure 0
set sv_allowDownload 1
set sv_fastDownload 1
set cl_allowDownload 1

The value is CVAR_ARCHIVE on the client, so it persists into the player's config_mp.cfg and subsequent servers benefit too.

A stock 1.1 server has no equivalent mechanism.

HTTP fast download (CoD2, CoD4, WaW)

CoD2 and later support an HTTP redirect. This is the only sane way to distribute custom content:

set sv_allowDownload 1
set sv_wwwDownload 1
set sv_wwwBaseURL "http://files.example.com/cod2"
set sv_wwwDlDisconnected 0

Those four values are what the CoD4X documentation specifies, and they work unchanged on World at War.

On CoD2 you will also find guides recommending sv_allowDownload 0 alongside sv_wwwDownload 1, to force HTTP and refuse the slow UDP fallback entirely. Both arrangements are in use. Start with sv_allowDownload 1; if you would rather no client ever hits the UDP path, try 0 and confirm with a real client before trusting it.

Path layout

The client appends the relative path it needs to sv_wwwBaseURL. If the missing file is main/mp_mymap.iwd and the base URL is http://files.example.com/cod2, the client requests:

http://files.example.com/cod2/main/mp_mymap.iwd

So your web root must mirror the server's directory structure, including main/ and any mods/<name>/ directories. On CoD4 and World at War, custom maps live under usermaps/<mapname>/ rather than main/.

Directory names must be lowercase on CoD4. The lookup is case-sensitive, so Mods/ or UserMaps/ 404s.

Getting the layout wrong is the number one cause of "fast download does not work" — the server is fine, the URL 404s, and the client silently falls back to the slow UDP path or fails outright.

Verify by hand before blaming the game:

curl -I http://files.example.com/cod2/main/mp_mymap.iwd

nginx configuration

server {
    listen 80;
    server_name files.example.com;

    root /srv/fastdl;

    # only ever serve game content
    location ~* \.(iwd|pk3|ff)$ {
        add_header Cache-Control "public, max-age=2592000, immutable";
        access_log off;
        try_files $uri =404;
    }

    location / { return 404; }
}

With /srv/fastdl/cod2/main/mp_mymap.iwd on disk. Keep it on the same box as the game server unless you have a reason not to; the bandwidth is trivial and the moving parts are fewer.

CoD1 has no HTTP download

CodExtended registers sv_wwwBaseURL as a cvar, but nothing reads it — the download code path is dead. Do not spend an evening on it as people periodically do. CoD1 is UDP-only.

Which files are actually pushed

Any pak the server references is offered to clients. There is no vanilla mechanism to mark a pak server-only, which matters when your mod contains server-side script you do not want redistributed, or files that would break clients elsewhere.

CodExtended adds one: a pak whose basename contains srv, svr or server is excluded from the download list. The server loads it, clients never see it.

This is also the correct way to ship a modified playeranim.script. That file parses into a parse-order-indexed animation table, and the server networks indices into it. A client that downloaded a re-ordered or trimmed table from your server will then crash with an "animation error" on a stock server. Never put a non-stock playeranim.script in a downloadable pak.

Checklist when downloads are not working

1. Is sv_allowDownload 1 actually set on the running server? Read it back over rcon, do not trust the config file — see the rcon guide.
2. Does curl -I on the exact URL the client would build return 200?
3. Does the web root mirror main/ and mods/?
4. Is sv_pure fighting you? Try sv_pure 0 as a diagnostic.
5. On CoD1 1.1, is the client's cl_allowDownload set at all?
6. Is the pak filename sorting after the stock paks? See installing mods.