Fixes for FileUploadBase.java

[Earl Hood <ea...@earlhood.com>]

Attached is a patch to FileUploadBase.java that fixes a couple of bugs:

1. Handle correctly a boundary parameter value surrounded by quotes.

2. Case-insensitive matching of content-type values and parameter names.
   For example, MULTIPART/FORM-DATA and multipart/form-data are the
   same thing.

I was going to do charset stuff, but noticed that the latest CVS version
does handle this now, so the patch provided is against a recent nightly
build.

There is a change where some stricter formating is enforced.  For example,
if a part does not define a content-disposition, and exception is thrown.
There is a comment asking if this is desired.  It is not clear from
looking at the code and conformant a post should be.  IMO, it should
be, or, conformance should be configurable.  Malformed data can
indicate application errors (and possible security issues), so quietly
ignoring errors should probably be avoided.

=====

Re: Fixes for FileUploadBase.java

[Earl Hood <ea...@earlhood.com>]

--- Joe Germuska <Jo...@Germuska.com> wrote:
> At 11:23 AM -0800 3/23/04, Earl Hood wrote:
> >There is a change where some stricter formating is enforced.  For example,
> >if a part does not define a content-disposition, and exception is thrown.
> >There is a comment asking if this is desired.
...
> I'd suggest that this be switchable, and default to not throwing an 
> exception, for backwards compatibility reasons.  Also, you're 
> ultimately relying on browser authors to implement the spec 
> perfectly, and given the variability I've seen in things like 
> assigning content-types, I think it's best to allow for browser 
> variation in how dispositions are handled also.

Agreed.  It then raises two questions:

* Which errors always raise exception?  For example, is a missing
  content-disposition always raise or error, or only when in strict
  mode?  If not always raise, need to define behavior (e.g. quietly
  ignore?).

  For simplicitly, in non-strict mode, any format errors are ignored,
  which may include completely ignoring an entity (of course, fatal
  errors should always throw an exception like a missing boundary
  delimiter).

  In strict-mode, if there is data that does not conform to the RFCs
  will raise an exception.

* How can strictness be specified?  Via a system property or some
  method call?  Or both?  It appears that if done via a method call,
  it would be a method on the FileUploadBase class.

For more flexibility, it may be useful to support an exception callback
handler.  For example, someone may want to have non-strict parsing, but
still receive messages when there are parsing errors.  I'd probably
use this to hook into a logger so i can log the problems and see
which clients are sending malformed data to see how common non-standard
posts are.

If there are no objections, I can take a stab at making some modifications
and submit a new patch.  However, if some of the items are not appropriate
for the project, or someone else prefers to make the changes, I will make a
local variation of fileupload for what I need.

--ewh


=====


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: Fixes for FileUploadBase.java

[Joe Germuska <Jo...@Germuska.com>]

At 11:23 AM -0800 3/23/04, Earl Hood wrote:
>There is a change where some stricter formating is enforced.  For example,
>if a part does not define a content-disposition, and exception is thrown.
>There is a comment asking if this is desired.  It is not clear from
>looking at the code and conformant a post should be.  IMO, it should
>be, or, conformance should be configurable.  Malformed data can
>indicate application errors (and possible security issues), so quietly
>ignoring errors should probably be avoided.

I'd suggest that this be switchable, and default to not throwing an 
exception, for backwards compatibility reasons.  Also, you're 
ultimately relying on browser authors to implement the spec 
perfectly, and given the variability I've seen in things like 
assigning content-types, I think it's best to allow for browser 
variation in how dispositions are handled also.

Thanks (from another user) for providing a patch, though!

Joe
-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
       "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
             -- Jef Raskin

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org