3 ms·

NGinx, Kube-NGINX, Apache, Traefik all default to normalizing request paths per reference of RFC 3986 [1]. This behavior can be disabled when requests are prox

by Bender 7mo ago

NGinx, Kube-NGINX, Apache, Traefik all default to normalizing request paths per reference of RFC 3986 [1]. This behavior can be disabled when requests are proxied to resources on the back-end that require double-slashes. I only reference the RFC to describe what they are talking about, not why they default to merging. They all agreed on a decision as one was not made for them. To generalize by saying "incorrect" is incorrect. The correct answer is that it depends on the requirements in the given implementation. Making such generalizations will just lead to endless arguing. If there is still any debate then a group must vote to deprecate and replace the existing RFC with a new RFC that requires that merging slashes MUST be either be always enabled or always disabled using verbiage per RFC 2119 [2] and optionally RFC 6919 [3]. Even then one may violate an RFC is there is a need to do so and everyone has verified, documented and signed off that doing so has not introduced any security or other risks in the given implementation and if such a risk is identified that it will be remediated or mitigated in a timely manor. [Edit] For clarification the reason I am linking to RFC 3986 is that it only defines path characteristics and does not explicitly say what to do or not to do. Arguments will persist until a new RFC is created rather than blog and stack overflow posts. Even then people may violate the RFC if they feel it is safe to do so. I do not know how to reword this to make it less confusing. [1] - https://datatracker.ietf.org/doc/html/rfc3986 https://datatracker.ietf.org/doc/html/rfc3986 [2] - https://datatracker.ietf.org/doc/html/rfc2119 https://datatracker.ietf.org/doc/html/rfc2119 [3] - https://datatracker.ietf.org/doc/html/rfc6919 https://datatracker.ietf.org/doc/html/rfc6919

embedding-shape 7mo ago
> Making such generalizations will just lead to endless arguing But 80% of all programming blog posts on the internet rely on being able to make sweeping generalizations across the ecosystem! Without this, we basically have nothing left to argue about. Caring about tradeoffs, contexts, nuance and not just cargoculting our way into a distributed architecture for a app with 10 users just sounds so 90s and early 00s. We're now in the future and we're all outputting the same ̶t̶o̶k̶e̶n̶s̶ code, so obviously what is the solution in my case, surely must be the solution in your case too.
- Bender 7mo ago
  Without this, we basically have nothing left to argue about. My theory is that the codex [1] was created not to stop arguments but rather to shorten them so that we can find a path forward, get back to work and accomplish some mission. [1] - https://www.youtube.com/watch?v=nfKFHTaGzuU https://www.youtube.com/watch?v=nfKFHTaGzuU
cxr 7mo ago
Both you and the original author cite the same RFC to support your arguments. Passages from RFC 3986 comprise the bulk of the original post. The difference between the support for your argument and theirs is that they call out the specific sections in the RFC that they claim are relevant to the issue at hand and your comment only broadly references the RFC by name. In any case, even if they, too, merely gestured to its existence, claiming that it supports their position, then appearing here with a bare claim that RFC 3986 supports the opposing side without further elaboration is not exactly strong candidate for a path to a fruitful resolution.
- mjmas 7mo ago
  Agreed. Reading through the RFC it certainly appears to support the blog article. And looking around I found this SO answer noting nothing in the RFC: https://stackoverflow.com/a/24661288 https://stackoverflow.com/a/24661288
- Bender 7mo ago
  In any case, even if they, too, merely gestured to its existence That is entirely my point. If the author wants to disable merge slashes then they need to replace the RFC I linked to with one that explicitly says what to do or not do using strong verbiage that is explicit as I explained. Blog articles and Stack Overflow threads will not set a standard. If people interpret the RFC differently than I in that they feel it is explicit vs vague then please contact all of the web daemon maintainers to have them correct their default behavior. Just know ahead of time that two of them are quite challenging to have these discussions with.
  - cxr 7mo ago
    > That is entirely my point. If the author wants to disable merge slashes then they need to replace the RFC I linked to with one that explicitly says what to do or not do using strong verbiage that is explicit as I explained. That doesn't seem to be the case. You said, "NGinx, Kube-NGINX, Apache, Traefik all default to normalizing request paths per reference of RFC 3986". That's a strong claim, not an appeal to ambiguity. > Blog articles[…] will not set a standard. Blog posts absolutely have the power to influence future developments. That's historically how it has worked. "RFC" stands for "Request For Comments".

by Bender 7mo ago

embedding-shape 7mo ago

> Making such generalizations will just lead to endless arguing But 80% of all programming blog posts on the internet rely on being able to make sweeping generalizations across the ecosystem! Without this, we basically have nothing left to argue about. Caring about tradeoffs, contexts, nuance and not just cargoculting our way into a distributed architecture for a app with 10 users just sounds so 90s and early 00s. We're now in the future and we're all outputting the same ̶t̶o̶k̶e̶n̶s̶ code, so obviously what is the solution in my case, surely must be the solution in your case too.

Bender 7mo ago
Without this, we basically have nothing left to argue about. My theory is that the codex [1] was created not to stop arguments but rather to shorten them so that we can find a path forward, get back to work and accomplish some mission. [1] - https://www.youtube.com/watch?v=nfKFHTaGzuU https://www.youtube.com/watch?v=nfKFHTaGzuU

cxr 7mo ago

Both you and the original author cite the same RFC to support your arguments. Passages from RFC 3986 comprise the bulk of the original post. The difference between the support for your argument and theirs is that they call out the specific sections in the RFC that they claim are relevant to the issue at hand and your comment only broadly references the RFC by name. In any case, even if they, too, merely gestured to its existence, claiming that it supports their position, then appearing here with a bare claim that RFC 3986 supports the opposing side without further elaboration is not exactly strong candidate for a path to a fruitful resolution.

mjmas 7mo ago
Agreed. Reading through the RFC it certainly appears to support the blog article. And looking around I found this SO answer noting nothing in the RFC: https://stackoverflow.com/a/24661288 https://stackoverflow.com/a/24661288
Bender 7mo ago
In any case, even if they, too, merely gestured to its existence That is entirely my point. If the author wants to disable merge slashes then they need to replace the RFC I linked to with one that explicitly says what to do or not do using strong verbiage that is explicit as I explained. Blog articles and Stack Overflow threads will not set a standard. If people interpret the RFC differently than I in that they feel it is explicit vs vague then please contact all of the web daemon maintainers to have them correct their default behavior. Just know ahead of time that two of them are quite challenging to have these discussions with.
- cxr 7mo ago
  > That is entirely my point. If the author wants to disable merge slashes then they need to replace the RFC I linked to with one that explicitly says what to do or not do using strong verbiage that is explicit as I explained. That doesn't seem to be the case. You said, "NGinx, Kube-NGINX, Apache, Traefik all default to normalizing request paths per reference of RFC 3986". That's a strong claim, not an appeal to ambiguity. > Blog articles[…] will not set a standard. Blog posts absolutely have the power to influence future developments. That's historically how it has worked. "RFC" stands for "Request For Comments".