Ticket #835 (enhancement)
Opened 5 months ago
Last modified 3 weeks ago
autotags fail on unicode characters
Status: closed (fixed)
| Reported by: | cpbug@mvs.za.org | Assigned to: | lawouach |
|---|---|---|---|
| Priority: | low | Milestone: | 3.1 |
| Component: | CherryPy code | Keywords: | |
| Cc: |
If the etags.autotags is on, cherrypy crashes (line 43, cptools.py) when encountering unicode characters, because md5 hashing cannot handle it. Suggested fix: either use python's builtin hash() instead of md5 (probably faster) or first encode the string to utf8 or some other ascii representation.
-- Melt van Schoor
Change History
07/04/08 09:17:38: Modified by lawouach
- owner changed from fumanchu to lawouach.
- priority changed from normal to low.
- status changed from new to assigned.
- type changed from defect to enhancement.
07/04/08 09:46:04: Modified by guest
My application happens to be configured to use the encoding tool, but clearly the response has not yet been encoded at this point. Perhaps this could be fixed by twiddling the tool priorities so encode runs first? -- MvS
07/04/08 09:52:43: Modified by lawouach
That's a good point actually. Currently the decode tool is set to priority 70, you might try with the etags tool priority set to 71.
07/05/08 10:40:06: Modified by guest
Yes that solves it, thanks. Suggest: change the etags default priority. Also, perhaps using python's builtin hash() instead of md5 in any case. --MvS
07/05/08 11:44:57: Modified by fumanchu
- status changed from assigned to closed.
- resolution set to fixed.
- milestone set to 3.1.
Fixed in [2013].
11/08/08 11:40:52: Modified by fumanchu
Backported to branches/3.1.x in [2066].
I think it should be up to the application to perform that encoding accordingly to their setup. I know Robert might argue UTF-8 is a rather sound default but I don't like that kind of assumption much.
I'd rather update the doc.