It is incorrect to "normalize" // in HTTP URL paths

Specs say keep the double slashes; devs say 'we're stripping them anyway'

TLDR: Standards say double slashes in URLs are meaningful and shouldn’t be auto-collapsed, but developers are split: some keep them for special routing, others strip them for safety and compatibility. It matters because a tiny change can send users to the wrong place—or open the door to old exploits.

Brace yourselves: the internet is having a nerd fight over… double slashes. A new explainer says collapsing // to / in a web address isn’t “normalizing” at all — the rules actually allow empty segments, so those two slashes can mean something. Translation: changing // to / can point you to a different place. The Lobsters crowd? Split down the middle and throwing popcorn.

On one side, the spec purists: the standards say hands off, so hands off. On the other, the battle-hardened pragmatists rolling their eyes: “we’ve been folding slashes for decades because real websites are messy.” One commenter likened ignoring this to grammar pedantry — the Oxford comma of URLs — while another called URL handling a “minefield” where every tool disagrees and mapping links to your hard drive only makes the explosions bigger.

Then came the twist: some devs actually use // on purpose as a secret doorway for embedded content that won’t clash with real files. Others warn that fancy theory melts under real-world heat: sites abuse weird URL tricks, and security teams have chopped out double slashes to block old-school exploits. The vibe? Spec vs. Street. And the memes? “Not your filesystem, honey,” and a collective sigh that the web runs on duct tape, vibes, and double slashes.

Key Points

  • Collapsing “//” to “/” in HTTP URL paths is not valid normalization under URI syntax.
  • RFC 3986 permits empty path segments, making double slashes syntactically meaningful.
  • The ABNF in RFC 3986 (e.g., path-abempty and segment) allows empty segments, so “//” can represent an empty segment.
  • Removing double slashes alters the parsed sequence of path segments and can change semantics.
  • HTTP (RFC 9110) adopts the RFC 3986 URI path grammar for request targets, so the same rules apply to HTTP URLs.

Hottest takes

It is probably “incorrect”, but given the established actual usage over the decades, it’s most likely what you need to do nevertheless — WesolyKubeczek
// is useful if the server needs to serve both static files in the filesystem, and embedded files like a webpage. — mjs01
We cut those and few others coz historically there were exploits relying on it — PunchyHamster
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.