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 18 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 11 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 34 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 22 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“.