commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earl Hood <e...@earlhood.com>
Subject Re: Fixes for FileUploadBase.java
Date Tue, 23 Mar 2004 22:25:19 GMT
--- Joe Germuska <Joe@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


Mime
View raw message