📁 HTTP Header Checker for File Preparation — The Case Study

🔍 Discovery: Maya runs the first header audit

Before touching the CloudFront configuration, Maya decided to audit the HTTP headers on a representative sample of their asset URLs. She knew from experience that CDN migrations expose header problems — wrong Content-Type headers, missing cache directives, incorrect Content-Disposition — that were "tolerated" by direct browser connections but break when a CDN intermediates. She opened the HTTP Header Checker and started pasting asset URLs.

"I figured I'd find maybe two or three minor issues — a missing Cache-Control on some old files, maybe a Content-Type mismatch on a legacy ZIP download. I did not expect to find eleven distinct header problems across five different file types. By the third URL, I realized we couldn't migrate anything until we fixed the origin headers."— Maya, Team Lead, CloudDesk

By 10:30 AM, Maya had audited 60 asset URLs — 10 samples from each of six file type categories. The HTTP Header Checker revealed 11 distinct header misconfigurations, grouped into five problem categories. Here is every problem, as Maya found it, and how the team fixed each one.

🗂️ Category 1: Wrong Content-Type Headers (3 problems)

Maya started with the PDF reports — the platform's most-downloaded asset type, with 12,000 downloads per month. She pasted a PDF URL into the HTTP Header Checker.

The origin server was serving every PDF with application/octet-stream — the generic "this is binary data" MIME type. Browsers downloading directly from the origin usually guessed the file type from the .pdf extension and opened it correctly. But CloudFront would treat application/octet-stream literally: no compression optimization, no byte-range support for partial downloads, no integration with CloudFront's PDF-specific edge features. Worse, CloudFront's cache key would be based on a generic content type, meaning all binary files — PDFs, ZIPs, DMGs, EXEs — would share cache entries, causing cache poisoning where a user requesting a PDF might receive a cached ZIP file with the same cache key.

Maya found the same problem on two more file types: SVG images served as text/plain (instead of image/svg+xml) and WebP images served as application/octet-stream (instead of image/webp). The WebP problem was particularly insidious — CloudFront has automatic WebP conversion for compatible clients, but it only activates when the origin correctly identifies the file as image/webp.

📥 Category 2: Missing Content-Disposition Headers (2 problems)

Next, Maya checked the software installer downloads — a Windows .exe and a macOS .dmg. Both downloaded correctly from the origin, but she knew CDNs handle Content-Disposition differently. She checked the headers.

Without a Content-Disposition: attachment; filename="clouddesk-setup-3.7.2.exe" header, browsers make their own decision about whether to display or download the file. Most browsers download .exe and .dmg files by default — but some corporate proxy environments and older browsers attempt to render unknown binary types inline, resulting in screens full of gibberish. The CDN wouldn't add this header on its own. Maya also found the same problem on the ZIP archives: no Content-Disposition header meant the browser might unzip and display the contents inline instead of prompting a download.

⚡ Category 3: Missing or Misconfigured Cache Headers (3 problems)

This was the category Maya was most worried about — and it proved to be the most damaging. She checked the Cache-Control headers on their highest-traffic assets: the product screenshots (PNG images loaded on the marketing site), the tutorial videos (MP4 files), and the API documentation ZIP archives.

Three different cache misconfigurations, three different failure modes. The product images had no-cache — a leftover from a debugging session six months ago that nobody reverted. CloudFront would respect it: every image request would hit the origin, generating 40,000 unnecessary origin requests per day. The tutorial videos had no Cache-Control header at all — CloudFront would apply its default TTL (24 hours), which is far too short for video content that hasn't changed in two years. The API documentation ZIPs had private, max-age=0 — CloudFront wouldn't cache them at all, meaning every user who downloaded the 45MB ZIP file pulled it from the origin server in Virginia, even users in Tokyo and Frankfurt.

📏 Category 4: Missing Content-Length and ETag Headers (2 problems)

Maya noticed that the HTTP Header Checker wasn't showing Content-Length headers on any of the large files — the software installers, the tutorial videos, the ZIP archives. This header tells the browser (and the CDN) exactly how many bytes to expect. Without it, the browser can't show a download progress bar, and the CDN can't verify it received the complete file from the origin.

She also noticed that ETag headers were missing on all assets — the origin was using chunked transfer encoding without generating entity tags. Without ETags, the CDN's conditional revalidation (If-None-Match requests) doesn't work, meaning every cache expiry triggers a full file download from the origin rather than a lightweight "has this changed?" check.

🔐 Category 5: Missing Security Headers on Asset Domain (1 problem)

The final problem was subtle. Maya checked the security headers on the asset subdomain (assets.clouddesk.com) and found zero security headers — no Strict-Transport-Security, no X-Content-Type-Options. While these don't directly affect file downloads, their absence meant that if an attacker ever compromised the asset domain's DNS, they could serve malicious files over HTTP with no browser-level protection. The CDN migration was the right moment to add them.