On Mon, Nov 25, 2013 at 10:54 AM, RjOllos <rjol...@gmail.com> 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 <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%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 trac-dev+unsubscr...@googlegroups.com.
To post to this group, send email to trac-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-dev.
For more options, visit https://groups.google.com/groups/opt_out.
