4 ms·
One thing that drives me mad on the Python side of things is the way frameworks and middleware (even the WSGI spec) corrupt the most basic "quoting" mechanism o
by saltcured 3y ago
One thing that drives me mad on the Python side of things is the way frameworks and middleware (even the WSGI spec) corrupt the most basic "quoting" mechanism of RFC 3986. All of these layers of trying to be clever or friendly subvert the correctness of the original concept. And these broken approaches become precedents that reinforce in the culture of web breakage and compatibility.
Specifically, "reserved" characters have a different meaning from their URL quoted form. It is obvious that the intent of this was to allow their use as meta-syntax to separate parts of a URL that might then have the quoted form embedded in them. But every stupid middleware layer that tries to unquote _before_ parsing and routing is throwing away this information and making it impossible to know what was the original meta-syntax and what was embedded quoted material that might be a fragment derived from arbitrary, user-generated content.
- richbell 3y agoThat sounds frustrating. Can you provide an example of how they mangle quoted URLs?
- saltcured 3y agoIf I can get the formatting to work here... the simplest example would be: /foo/element%2Ftwo/bar this three element path ought to be easily parsed and routed to a handler for "foo" that can have two args which would receive the path elements: element%2Ftwo bar in other words, one path element has a quoted slash in it. But instead, it gets unquoted at the WSGI layer into: /foo/element/two/bar and then such routing would fail entirely or get the arguments wrongly chopped up, depending on how routing patterns work in the framework. This same problem applies to all the "reserved" chars from the spec, e.g. slashes, semi-colons, colons, equal-sign, asterisk, parentheses, and more.