Ticket #248 (defect)
Opened 3 years ago
Last modified 3 years ago
DecodingFilter and URIs
Status: closed (fixed)
| Reported by: | steadicat | Assigned to: | rdelon |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.1 |
| Component: | CherryPy code | Keywords: | |
| Cc: | cherrypy@attardi.org |
DecodingFilter? should also decode the request path and the parameter names, not only the parameter values. See:
http://www.w3.org/TR/html4/appendix/notes.html#h-B.2
According to the spec, it should always use UTF-8, though allowing the user to override this is probably acceptable.
This fix makes even more sense when using positional parameters:
def default(self, word): return word
With the above code, there is no reason why /?word=perché should work and /perché shouldn't.
Change History
08/27/05 14:50:15: Modified by fumanchu
- status changed from new to closed.
- resolution set to fixed.
This ticket raises three different concerns.
1. URL's, param keys and param values which have been "% HEX HEX" encoded should all be decoded. This was partially implemented already, and is now done earlier in the request process with changeset [561].
2. Positional params which have been utf-8 encoded should be decoded so that the example code (above) works. If this didn't work before it does now with [561]. See test.test_core.Params.default for an example.
3. Parameter values ("?key=value") which have been utf-8 encoded are already decoded with the decoding filter; the keys should be decoded likewise. However, this breaks CherryPy in a fundamental way, since CP passes parameters as function keyword arguments; Python requires those keys to be strings, not unicode. Therefore, utf-8-encoded keys should not be decoded, but should be passed as-is, IMO. Therefore, I'm closing this as fixed. Please open a separate ticket if you want some other behavior on this particular point, since the other issues have been fixed.