This post comes from Daniel Stenberg — the author and lead maintainer of curl, the tool that quietly moves data across essentially every operating system, car dashboard, satellite, and smart fridge on the planet. When Stenberg writes about a corner of curl's behavior, it's almost always a small window into a much larger problem: how do you build software that has to gracefully handle every weird, malformed, or hostile input the internet can throw at it?

The title hints at a deceptively simple question: when you run curl -O to save a URL to disk, what filename should curl use if the URL doesn't actually contain one? Think about the edge cases:

• A URL like https://example.com/ — just a slash, no path segment to derive a name from
• A redirect that lands somewhere with no obvious filename
• A Content-Disposition header that suggests a name containing slashes, null bytes, or path traversal sequences
• Names that would clobber existing files or shell-inject if handled naively

This is exactly the kind of problem where the "obvious" solution is a security disaster. A tool that blindly trusts server-supplied filenames is one Content-Disposition: attachment; filename="../../.ssh/authorized_keys" away from ruining someone's day. Curl has been shipping since 1996, which means Stenberg has probably seen every variant of this attack and every legitimate use case that looks suspiciously like an attack.

What makes Stenberg's posts consistently valuable to a technical audience is that they document the reasoning behind seemingly trivial defaults. There's institutional knowledge here — decades of bug reports, CVEs, and mailing-list arguments distilled into a few hundred words. If you've ever written a downloader, a scraper, a browser extension, or anything that persists remote content to disk, you have almost certainly gotten this wrong, and this post likely tells you how.

There's also a broader lesson about API design: every function that produces a string eventually gets asked "what do you return when there's nothing to return?" — and the answer is almost never "just return empty and let the caller figure it out."