3 ms·

> 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

> 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 6mo ago
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 6mo ago
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 6mo ago
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 6mo ago
  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/9781788623551/f4282011-09ff-4e63-99ec-173ff1b13e9c.xhtml#:~:text=By%20default%2C%20if%20the%20client,location%20pattern%20will%20be%20matched. 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#merge_slashes https://nginx.org/en/docs/http/ngx_http_core_module.html#mer...
  - cxr 6mo ago
    > 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 6mo ago
      > 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#merge_slashes 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 6mo ago
        > 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.

leni536 6mo ago

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 6mo ago

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 6mo ago

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 6mo ago
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/9781788623551/f4282011-09ff-4e63-99ec-173ff1b13e9c.xhtml#:~:text=By%20default%2C%20if%20the%20client,location%20pattern%20will%20be%20matched. 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#merge_slashes https://nginx.org/en/docs/http/ngx_http_core_module.html#mer...
- cxr 6mo ago
  > 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 6mo ago
    > 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#merge_slashes 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 6mo ago
      > 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.