On Mon, Nov 25, 2013 at 10:54 AM, RjOllos <[email protected]> wrote:
>
>
> On Monday, November 25, 2013 7:39:17 AM UTC-8, Olemis Lang wrote:
>
>>
>> On Fri, Nov 22, 2013 at 8:18 PM, RjOllos <[email protected]> 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 <[email protected]> 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%0A
>>>>>
>>>>
>>>> IMO 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 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 .
>>
>>
>>> 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 .
>>
>>
>
OS = Ubuntu 10.04
> Have you reproduced the issue?
>
In Opera (Version=12.02 , Build=1578 , Platform=Linux , System=x86_64,
2.6.32-40-generic) the file selection input control renders a red warning
message saying "specified one or more files that could not be found" so the
file upload is not even possible .
In Firefox 11.0 the new line char is replaced by a single whitespace (i.e.
%20) char before upload so there's no actual error
Finally ... when using trac-admin to upload "x\ny.txt" file I can actually
see /attachment/ticket/14/x%0Ay.txt link in attachments list . On click I
get an error message :
{{{
Error: Invalid Attachment
Attachment 'ticket:14: x' does not exist.
}}}
JFTR: I tried both Trac (/trunk) + Bloodhound 0.8-dev ;)
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.
>
Now I understand your previous statement ...
--
Regards,
Olemis - @olemislc
Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/trac-dev.
For more options, visit https://groups.google.com/groups/opt_out.
