On Thursday, November 21, 2013 5:53:21 AM UTC-8, Chris Nelson wrote:
>
> My personal feeling is to discourage such an insane filename (report it
> in a warning?) in the first place. Neither have I encountered such a
> wired filename before nor can I see a valid use case and consequently
> the need to support it. Is this unrealistic thinking?
I agree. Spaces in file names is one thing but vertical white space?
That's insane.I'm in agreement on the insane aspect of it, but it seems to work just fine to create a file with a linefeed character on TracStandalone:
$ echo "Some text" > "myfile"The linefeed character is encoded as %0A: myfile%0A
On Thu, Nov 21, 2013 at 5:42 PM, RjOllos <rjo...@gmail.com> wrote:
On Thursday, November 21, 2013 5:53:21 AM UTC-8, Chris Nelson wrote:[...]>
> My personal feeling is to discourage such an insane filename (report it
> in a warning?) in the first place. Neither have I encountered such a
> wired filename before nor can I see a valid use case and consequently
> the need to support it. Is this unrealistic thinking?
I agree. Spaces in file names is one thing but vertical white space?
That's insane.I'm in agreement on the insane aspect of it, but it seems to work just fine to create a file with a linefeed character on TracStandalone:
$ echo "Some text" > "myfile"The linefeed character is encoded as %0A: myfile%0AIMO let's better filter such file upload requests and return an HTTP 400 Bad Request back to the caller with an informative message .
On Friday, November 22, 2013 9:48:37 AM UTC-8, Olemis Lang wrote:On Thu, Nov 21, 2013 at 5:42 PM, RjOllos <rjo...@gmail.com> wrote:
On Thursday, November 21, 2013 5:53:21 AM UTC-8, Chris Nelson wrote:[...]>
> My personal feeling is to discourage such an insane filename (report it
> in a warning?) in the first place. Neither have I encountered such a
> wired filename before nor can I see a valid use case and consequently
> the need to support it. Is this unrealistic thinking?
I agree. Spaces in file names is one thing but vertical white space?
That's insane.I'm in agreement on the insane aspect of it, but it seems to work just fine to create a file with a linefeed character on TracStandalone:
$ echo "Some text" > "myfile"The linefeed character is encoded as %0A: myfile%0AIMO let's better filter such file upload requests and return an HTTP 400 Bad Request back to the caller with an informative message .What is your reasoning for throwing an error on the request?
It seems that Trac handles the case without any issue and nothing breaks when uploading a file with a newline in the filename;
it's such an odd scenario that I can't see the need to add any special handling for it in the codebase.
I might feel differently if Trac couldn't handle the file.
On Fri, Nov 22, 2013 at 8:18 PM, RjOllos <rjo...@gmail.com> wrote:On Friday, November 22, 2013 9:48:37 AM UTC-8, Olemis Lang wrote:On Thu, Nov 21, 2013 at 5:42 PM, RjOllos <rjo...@gmail.com> wrote:
On Thursday, November 21, 2013 5:53:21 AM UTC-8, Chris Nelson wrote:[...]>
> My personal feeling is to discourage such an insane filename (report it
> in a warning?) in the first place. Neither have I encountered such a
> wired filename before nor can I see a valid use case and consequently
> the need to support it. Is this unrealistic thinking?
I agree. Spaces in file names is one thing but vertical white space?
That's insane.I'm in agreement on the insane aspect of it, but it seems to work just fine to create a file with a linefeed character on TracStandalone:
$ echo "Some text" > "myfile"The linefeed character is encoded as %0A: myfile%0AIMO let's better filter such file upload requests and return an HTTP 400 Bad Request back to the caller with an informative message .What is your reasoning for throwing an error on the request?It seems there is consensus on the fact that new line chars should not be allowed . Considering this fact then we have (at least) three options :1. Do not allow uploading such attachments at all2. Allow uploads and support new line chars in attachments web UI3. Keep things as they are now i.e. allow uploads and still fail to match attachment web UI requestsIt seems to me that (1) is the best approach .It seems that Trac handles the case without any issue and nothing breaks when uploading a file with a newline in the filename;I see no point in allowing file uploads that will not be reflected in web UI afterwards .
Have you reproduced the issue?
My point has been, when I tried to reproduce I found that the newline was encoded, and the files ARE viewable in the web ui.
I found no issues when uploading a file that has a newline in the filename.
4. Replace unicode control codes with spaces.
>> 1. Do not allow uploading such attachments at all
>> 2. Allow uploads and support new line chars in attachments web UI
>> 3. Keep things as they are now i.e. allow uploads and still fail to
>> match attachment web UI requests
>>
>> It seems to me that (1) is the best approach .
See attachment-ctrl-codes.diff.
Hi RjOllos,
Sorry for the late reply. Yes we do, my understand is that it was uploaded as an attachment to a milestone.
Ian