> Wait, are there any implementations that wrongly collapse double-slashes?

> nginx with merge_slashes

How can it be wrong if it is server-side? If the server wants to treat those paths equally, it can if it wants to.

It would only be wrong if a client does it and requests a different URL than the user entered, right?

▲ leni536 3 hours ago | parent | next [-]

It can't be. It's the same confusion as "email address normalization" being wrong (for example when gmail ignores dots when mapping an address to an inbox).

It matters where the normalization happens, and server-side behavior is out-of-scope of these identifier RFCs.

▲ OoooooooO 3 hours ago | parent | prev | next [-]

Yeah I would say that falls under the origin defining both paths as equivalent.

> Therefore, collapsing // to / in HTTP URL path segments is not correct normalization. It produces a different, non-equivalent identifier unless the origin explicitly defines those two paths as equivalent.

▲ cxr 2 hours ago | parent | prev [-]

nginx is frequently used as a reverse proxy and not "the server" (or only to the extent that it's the client-facing server). Its defaults assume that it's fine to do a "normalization" pass to remove double slash, etc., even though that's potentially out of step with how the actual content/application server wishes to deal with those requests.

▲ echoangle 2 hours ago | parent [-]

That’s purely a server side configuration issue and has nothing to do with web standards though. There’s nothing that says that the internal communication on the server needs to follow the standards for user agents.

And at least according to this, the default setting is off so nginx actually is compliant unless you manually make it not be:

https://www.oreilly.com/library/view/nginx-http-server/97817...

EDIT: Actually it seems to be on by default:

https://nginx.org/en/docs/http/ngx_http_core_module.html#mer...

▲ mjmas 13 minutes ago | parent | next [-]

> And at least according to this, the default setting is off

It appears to not default to off on my install (AlmaLinux 10).

I just tested now. Cloudflare normalises ../ and ./ paths and then the nginx proxy appears to normalise // to /:

nginx log:

  1234:: - - [18/Apr/2026:12:59:05 +0000] "GET //test//doubleslash/url HTTP/1.1" 404 158 "-" "curl/8.19.0" "1234::"

lighttpd log:

  1234:: - - [18/Apr/2026:12:59:04 +0000] "GET /test/doubleslash/url HTTP/1.0" 404 158 "-" "curl/8.19.0"

	▲	echoangle 6 minutes ago \| parent [-]
		Actually I think you’re right, here it also says the default is on: https://nginx.org/en/docs/http/ngx_http_core_module.html#mer... Thanks for trying!

▲ cxr an hour ago | parent | prev [-]

> That’s purely a server side configuration issue

When it's the default, it's not a case of someone having configured nginx to do the thing described, as is their prerogative. It's nginx's defaulting to doing the wrong thing and requiring specific configuration to do the right thing. The author's position is that this violates the RFCs.

> and has nothing to do with web standards though

Yes it does. Prescriptions for how intermediate servers are or are not to munge data before passing it to the origin server are written directly into the HTTP RFCs. They're filled with references to this.

> There’s nothing that says that the internal communication on the server needs to follow the standards for user agents.

And is there anyone arguing that that's the case here?

▲

echoangle an hour ago | parent [-]

> When it's the default, it's not a matter of someone configuring nginx to do the wrong thing. It's nginx's defaulting to doing the wrong thing and requiring specific configuration to do the right thing.

This assumes that „the reverse proxy requests a different URL upstream from what it got as a request“ is wrong. Who says that it is?

And as I said, it doesn’t seem to be the default. But I can also continue defend it being the default because I think even as a default on it wouldn’t be wrong.

EDIT: Actually it seems to be on by default:

https://nginx.org/en/docs/http/ngx_http_core_module.html#mer...

> Yes it is. Prescriptions for how intermediate servers are or are not to munge data before passing it to the origin server is written directly into the HTTP RFCs. It's filled with references to them.

Which RFC forbids a reverse proxy from rewriting the request URL?

If I have a legacy PHP app that expects values as query strings and I use a reverse proxy to map the URL path to those query strings, is that wrong too? Would it be wrong if my reverse proxy did that by default?

▲

cxr 28 minutes ago | parent [-]

> This assumes that „the reverse proxy requests a different URL upstream from what it got as a request“ is wrong. Who says that it is?

For this case (double/multiple slash "normalization"), the author of this post is saying that—and they're saying RFC 3986 says so, too.

> Which RFC forbids a reverse proxy from rewriting the request URL?

Ibid.

> If I have a legacy PHP app that expects values as query strings and I use a reverse proxy to map the URL path to those query strings, is that wrong too? Would it be wrong if my reverse proxy did that by default?

Clearly, it's not wrong if you selected and/or configured a software package specifically for the purpose of providing that functionality. And clearly it is wrong if it were to do that when not configured to do anything other than act as generic middleware, with that software's creator(s) operating under the assumption that it's safe to do so all while arguing that it's standards-compliant.

	▲	echoangle 17 minutes ago \| parent [-]
		> For this case (double/multiple slash "normalization"), the author of this post is saying that—and they're saying RFC 3986 says so, too. No. The RFC says that the rewritten URL is not considered the same URL. But nothing says that the reverse proxy has to request the same URL. The rewrite is not a normalization, but nothing says that the reverse proxy is only allowed to do normalization. > Clearly, it's not wrong if you selected and/or configured a software package specifically for the purpose of providing that functionality. And clearly it is wrong if it were to do that when not configured to do anything other than act as generic middleware, with that software's creator(s) operating under the assumption that it's safe to do so all while arguing that it's standards-compliant. It’s not wrong and it is standards-compliant, because no standard says that the default has to be „pass the original URL on without rewriting it“.