Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 61682 invoked from network); 23 Mar 2004 19:47:34 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 23 Mar 2004 19:47:34 -0000 Received: (qmail 89502 invoked by uid 500); 23 Mar 2004 19:47:14 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 89323 invoked by uid 500); 23 Mar 2004 19:47:13 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 89243 invoked from network); 23 Mar 2004 19:47:12 -0000 Received: from unknown (HELO web60708.mail.yahoo.com) (216.109.117.231) by daedalus.apache.org with SMTP; 23 Mar 2004 19:47:12 -0000 Message-ID: <20040323192328.14483.qmail@web60708.mail.yahoo.com> Received: from [209.172.121.230] by web60708.mail.yahoo.com via HTTP; Tue, 23 Mar 2004 11:23:28 PST Date: Tue, 23 Mar 2004 11:23:28 -0800 (PST) From: Earl Hood Reply-To: earl@earlhood.com Subject: Fixes for FileUploadBase.java To: commons-dev@jakarta.apache.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-169525614-1080069808=:13905" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N --0-169525614-1080069808=:13905 Content-Type: text/plain; charset=us-ascii Content-Id: Content-Disposition: inline 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. ===== --0-169525614-1080069808=:13905 Content-Type: text/plain; charset=us-ascii --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org --0-169525614-1080069808=:13905--