On Fri, Nov 22, 2013 at 8:18 PM, RjOllos <rjol...@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 . > it's such an odd scenario that I can't see the need to add any special > handling for it in the codebase. > ... but maybe you're right and (3) is the best option considering ... performance ? > I might feel differently if Trac couldn't handle the file. > > If Trac could not handle the filename (as should be e.g. the case when file with name containing backslash char \ is uploaded from linux to a windows server) then Trac environment state would be consistent : os error , no attachments in server FS and thereby no match in web UI . -- 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.
