4 ms·

> One of the ways that DWiki (the code behind Wandering Thoughts) is unusual is that it strictly validates the query parameters it receives on URLs, including o

> One of the ways that DWiki (the code behind Wandering Thoughts) is unusual is that it strictly validates the query parameters it receives on URLs, including on HTTP GET requests for ordinary pages. If a HTTP request has unexpected and unsupported query parameters, such a GET request will normally fail. This goes counter to the robustness principle: Be conservative in what you do, be liberal in what you accept from others (https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle).

olliej 6y ago
Which we’ve increasingly moved away from because of some of the absurdities (and security problems) that it’s caused. Nowadays the w3c and es committees work hard to try and ensure no ambiguity is left in the spec, and have tests available early on, and do interop comparisons between engines to see if there’s anything missed.
- im3w1l 6y ago
  A big issue with being accepting is that you risk breaking things tomorrow when you no longer want to be as accepting. And it can prevent adding features that would play badly with others' out of spec implementations. Like if twitter adds these s=NN parameters, that means you can't use an s=NN parameter for your own purposes.
pwdisswordfish4 6y ago
All the worse for the ‘robustness’ principle then. https://tools.ietf.org/id/draft-iab-protocol-maintenance-04.html https://tools.ietf.org/id/draft-iab-protocol-maintenance-04.... (Shame this draft just expired before being finalised.)
treve 6y ago
The robustness principle is widely considered to be a bad practice these days. Strictly failing is a good thing, generally. Accepting arbitrary query parameters is pretty much a de facto exception though
- raxxorrax 6y ago
  You have to ensure you don't over-engineer specifications or it will be ignored as well. HTTP requests are one thing, imagine if we were strict on HTML validation. We now have robust browsers and I am not sure if that is only a bad thing. Although it would be nice if people would check their documents once or twice. edit: I don't think considering the principle as bad is a sensible approach as it doesn't mean to ignore errors in theory.
  - klodolph 6y ago
    > imagine if we were strict on HTML validation You don't have to imagine it, this actually happened. I don't remember the details, but back in the HTML 4 era, there was XHTML, and if you gave it an XML media type, many browsers would parse it as XML and reject the entire document if there was any error (and display nothing at all but an error message). There were a number of articles and blog posts about this back in the day.
- dfee 6y ago
  I feel that you’re right - it’s increasingly considered bad practice - but I’ve not seen this conversation play out. Of course, this often comes up in collaborative coding exercises (work, open source), so seeing a discussion on the topic would be helpful. Anyone have a link to such a discussion?
  - daurnimator 6y ago
    https://tools.ietf.org/html/draft-iab-protocol-maintenance-04 https://tools.ietf.org/html/draft-iab-protocol-maintenance-0...
- nmadden 6y ago
  As an example, rejecting unrecognised query parameters can cause ossification of web protocols. For example, I do a lot of work with OAuth and it is accepted security best practice now to use PKCE [1] on all authorisation requests [2]. However, despite the OAuth spec saying that authorisation servers MUST ignore unrecognised parameters [3], there are many major services that fail if you add a PKCE code_challenge parameter. This means generic client libraries either don't implement PKCE or have to maintain a list of sites that don't work (which gets stale over time) or have some risky downgrade logic. So there is a tradeoff between strict validation and allowing future expansion and upgrades. By all means strictly validate the parameters you need, but maybe don't reject parameters you don't recognise. [1]: https://oauth.net/2/pkce/ https://oauth.net/2/pkce/ [2]: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 https://tools.ietf.org/html/draft-ietf-oauth-security-topics... [3]: https://tools.ietf.org/html/rfc6749#page-19 https://tools.ietf.org/html/rfc6749#page-19

olliej 6y ago

Which we’ve increasingly moved away from because of some of the absurdities (and security problems) that it’s caused. Nowadays the w3c and es committees work hard to try and ensure no ambiguity is left in the spec, and have tests available early on, and do interop comparisons between engines to see if there’s anything missed.

im3w1l 6y ago
A big issue with being accepting is that you risk breaking things tomorrow when you no longer want to be as accepting. And it can prevent adding features that would play badly with others' out of spec implementations. Like if twitter adds these s=NN parameters, that means you can't use an s=NN parameter for your own purposes.

pwdisswordfish4 6y ago

All the worse for the ‘robustness’ principle then. https://tools.ietf.org/id/draft-iab-protocol-maintenance-04.html https://tools.ietf.org/id/draft-iab-protocol-maintenance-04.... (Shame this draft just expired before being finalised.)

treve 6y ago

The robustness principle is widely considered to be a bad practice these days. Strictly failing is a good thing, generally. Accepting arbitrary query parameters is pretty much a de facto exception though

raxxorrax 6y ago
You have to ensure you don't over-engineer specifications or it will be ignored as well. HTTP requests are one thing, imagine if we were strict on HTML validation. We now have robust browsers and I am not sure if that is only a bad thing. Although it would be nice if people would check their documents once or twice. edit: I don't think considering the principle as bad is a sensible approach as it doesn't mean to ignore errors in theory.
- klodolph 6y ago
  > imagine if we were strict on HTML validation You don't have to imagine it, this actually happened. I don't remember the details, but back in the HTML 4 era, there was XHTML, and if you gave it an XML media type, many browsers would parse it as XML and reject the entire document if there was any error (and display nothing at all but an error message). There were a number of articles and blog posts about this back in the day.
dfee 6y ago
I feel that you’re right - it’s increasingly considered bad practice - but I’ve not seen this conversation play out. Of course, this often comes up in collaborative coding exercises (work, open source), so seeing a discussion on the topic would be helpful. Anyone have a link to such a discussion?
- daurnimator 6y ago
  https://tools.ietf.org/html/draft-iab-protocol-maintenance-04 https://tools.ietf.org/html/draft-iab-protocol-maintenance-0...
nmadden 6y ago
As an example, rejecting unrecognised query parameters can cause ossification of web protocols. For example, I do a lot of work with OAuth and it is accepted security best practice now to use PKCE [1] on all authorisation requests [2]. However, despite the OAuth spec saying that authorisation servers MUST ignore unrecognised parameters [3], there are many major services that fail if you add a PKCE code_challenge parameter. This means generic client libraries either don't implement PKCE or have to maintain a list of sites that don't work (which gets stale over time) or have some risky downgrade logic. So there is a tradeoff between strict validation and allowing future expansion and upgrades. By all means strictly validate the parameters you need, but maybe don't reject parameters you don't recognise. [1]: https://oauth.net/2/pkce/ https://oauth.net/2/pkce/ [2]: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 https://tools.ietf.org/html/draft-ietf-oauth-security-topics... [3]: https://tools.ietf.org/html/rfc6749#page-19 https://tools.ietf.org/html/rfc6749#page-19