4 ms·
Yes, unfortunately WSGI is "broken by specification" in that all path parts are decoded before passing to the underlying application. This doesn't crop up that
by time4tea 5y ago
Yes, unfortunately WSGI is "broken by specification" in that all path parts are decoded before passing to the underlying application.
This doesn't crop up that often, but some schemes are completely broken by it, for example DOI, which can have parts like "10.1002/0470841559.ch1", and normalising the whole uri in one go will break. Path parts need to be normalised individually.
Edit: typo, replace 'design' with specification. Its not intended, probably, but a conforming implementation must implement something that cannot work with certain paths.
- ianbicking 5y agoI was involved with WSGI back when this was being decided... it was definitely a known problem, but a particularly good solution never revealed itself. The CGI variables it was based on had decoded semantics so it couldn't be redefined in place, we'd need some other names. Some gateways might have already decoded so recreating an accurate original URL might be hard in some deployments. There's another common key that includes the unencoded complete URL but WSGI had a split URL representing previous URL-prefix based dispatching (which came from CGI) and so there was some ambiguity there if you tried to make use of it. Two variables representing the same thing is a recipe for confusion and possible security problems, even worse when the two things have such subtly different quoting semantics. So it never really got fixed. Something like this is there to solve not just errors because of gateways doing decoding, but also browsers and email clients and everything else that might break a URL.