SvelteKit server-side SDK cookie forwarding: raw header vs event.cookies.getAll()

Problem

When a SvelteKit app needs to forward browser cookies to a backend API via a generated SDK (e.g., oazapfts), the server-side handle hook must attach cookies to outbound fetch calls. There are two approaches, and they behave differently in Docker and multi-service deployments.

Approach 1: event.cookies.getAll() (fragile)

sdk_defaults.headers.cookie = event.cookies
    .getAll()
    .map((cookie) => `${cookie.name}=${cookie.value}`)
    .join('; ');

SvelteKit's event.cookies API applies internal filtering — it only exposes cookies that SvelteKit "knows about" based on domain, path, and its own cookie-tracking rules. Cookies set by a separate backend service (e.g., via Set-Cookie with a domain the SvelteKit process doesn't track) may be silently excluded.

In a Docker Compose setup where the browser hits localhost:5183 (SvelteKit) and the backend runs as a separate service (api:8083), cookies set by the backend with domain=localhost were present in the browser's Cookie header but absent from event.cookies.getAll(). The SDK sent requests without auth cookies, and the backend returned 401. No error was thrown — the cookies were just silently missing.

Approach 2: Raw Cookie header (robust)

const rawCookie = event.request.headers.get('cookie');
if (rawCookie) {
    sdk_defaults.headers.cookie = rawCookie;
}
sdk_defaults.credentials = 'include';

This reads the raw Cookie header exactly as the browser sent it — every cookie, no filtering. The backend parses what it needs from the standard format. This works identically regardless of deployment topology: bare-metal, Docker Compose, Kubernetes, or any other setup where the SvelteKit server and backend are separate processes.

Why approach 2 is better

1. No silent filtering. event.request.headers.get('cookie') is the ground truth — it's what the browser actually sent. There's no layer between you and the cookies that might decide some don't qualify.

2. Deployment-agnostic. The cookie domain, path, and SameSite attributes that matter for browser-to-SvelteKit delivery are orthogonal to what matters for SvelteKit-to-backend forwarding. The raw header doesn't conflate these concerns.

3. Debuggable. When cookies are missing from event.cookies.getAll(), the failure mode is silent — the SDK just sends requests without auth, and you get unexplained 401s. With the raw header, if the cookie is missing, it was never sent by the browser (a real problem, not a framework filtering artifact).

4. Also set credentials: 'include' on the SDK defaults to ensure the fetch runtime honors credential settings on outbound requests.

When approach 1 is acceptable

If your SvelteKit app and backend share the same origin, or if SvelteKit sets and manages all cookies itself (no external Set-Cookie from a separate backend), event.cookies.getAll() works fine and gives you typed cookie access. The filtering only becomes a problem when cookies cross service boundaries.