On 03/09/2013 04:02 PM, Simone Tripodi wrote: >> I do not think its the responsibility of the users that our provided >> software is bug-free. If they do submit patches, great, if not, somebody >> has to step in. >> > > I agree, but at least a patch with unit test that proves the issue, > would certainly help. > >> The more interesting question for me is if there is any specific reason >> why this component has to be rushed out? Any important bugfix that >> somebody needs? I ask, because I see more bugs which seem to be easy to >> fix. Do you need help for that? > > as always, when working with me, any help is much more than > appreciated and welcomed, so if you have spare time to help me on > squashing bugs on FileUpload, I can only be more than happy :) > > I have anyway a silly questions: open bugs have never be blocking for > releases here, have I missed some discussion? > > Just for the sake of not looking impatient, I notified in ML that I > was going to cut a RC, asking for feedbacks before I open the VOTE > thread - got no reply, I went ahead :) > > TIA Thomas, looking forward to come back working with you!
I did look into more issues: Critical * FILEUPLOAD-212: after looking more carefully into it I think it is invalid, see the attached test * FILEUPLOAD-193: as stated in the comments already, this was most likely due to some non-supported filenames in a windows environment can be resolved as Invalid I guess Major * FILEUPLOAD-205: I think we should fix this, I outlined a possible fix in the comments. * FILEUPLOAD-199: we could copy the MimeUtility class (under CDDL license) and decode the header values with it, similar as we encode them in commons-email. * FILEUPLOAD-206: supporting content encoding for form-data would be really helpful I guess additionally, I resolved some more issues as duplicates of others, and provided some comments on others which I tried to reproduce but failed. We should also validate if FILEUPLOAD-188 is fixed by introducing the new contentLength() method which returns a long. btw. I am unsure about this change, as it now only looks at the Content-Length header. If none is set, the result it -1, but before we were returning request.getContentLength(). Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
