#11395 closed enhancement (fixed)
Replace unicode control codes with spaces in attachment filename — at Version 4
Reported by: | Ryan J Ollos | Owned by: | Ryan J Ollos |
---|---|---|---|
Priority: | normal | Milestone: | 1.1.3 |
Component: | attachment | Version: | |
Severity: | normal | Keywords: | unicode control codes |
Cc: | Ryan J Ollos | Branch: | |
Release Notes: |
Unicode control codes are replaced with spaces in attachment filenames. |
||
API Changes: | |||
Internal Changes: |
Description (last modified by )
It was discussed on the mailing list that control codes in attachment filename should be replaced with whitespaces.
Change History (4)
comment:1 by , 10 years ago
Description: | modified (diff) |
---|
comment:3 by , 10 years ago
Milestone: | next-stable-1.0.x → 1.0.3 |
---|---|
Owner: | set to |
Status: | new → assigned |
comment:4 by , 9 years ago
Milestone: | 1.0.3 → 1.1.3 |
---|---|
Release Notes: | modified (diff) |
Resolution: | → fixed |
Status: | assigned → closed |
It seemed least risky to finally push this to the trunk. Committed in [13603].
Note:
See TracTickets
for help on using tickets.
As mentioned on the mailing list, the following behaviors are seen:
Even with the patch, the browser will have the first chance to modify the filename. So as far as I can tell, if we implement some behavior in
AttachmentModule._do_save
to replace control codes with whitespace, it will really only help in the case that there are some browsers that pass along the filename with the control-codes still present.The following case was also mentioned on the mailing list:
When trying to view the file through the browser we get: No handler matched request to /attachment/wiki/WikiStart/file1 .txt.
I'm more convinced that this is hardly worth worrying about, but might something like the following work well?: log:rjollos.git:t11395
I don't understand everything that is going on inside of
_normalized_filename
, but at least we can easily write unit tests for it, and it might be appropriate fortrac.util
.