Hi Thomas, thanks a lot for your help, very appreciated! :)
> Critical > > * FILEUPLOAD-212: after looking more carefully into it I think it is > invalid, see the attached test > +1 I'd close it as `not a problem` > * 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 > yeah as above, it is a specific environment problem > Major > > * FILEUPLOAD-205: I think we should fix this, I outlined a possible > fix in the comments. > looks like you already have an idea how to handle it - do you feel comfortable on checkin-in the fix? > * 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. > +1 > * 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. > I haven't checked all of them - did you add 1.3 in the `fix version` field? > 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(). as you stated in FILEUPLOAD-179 I agree that "If none is present -1 is returned, so I guess it would be better that in this case the old "request.getContentLength()" is returned." thanks, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
