Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of craigmcc@gmail.com designates
 64.233.162.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references;
        b=muVJYaC4wrtomGc4mJ5dxnzG+nwVv3ThhgyHr0TqnDQZXDI110AsHQx582Vz2s7pJ6EoDjt2KYIlsXoqanDh0x9tZGNMgPVZxwNzSkmwng2JtNnypE5h1lVq+VlhxroYepucGLk30BtmAyVWL0mpJ/+4vk7TB0l1JU/QVC8KP0c=
Message-ID: <f8b39ace0604042021m31d024b4o148cde8f94c07272@mail.gmail.com>
Date: Tue, 4 Apr 2006 20:21:17 -0700
From: "Craig McClanahan" <craigmcc@apache.org>
Sender: craigmcc@gmail.com
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Subject: Re: [fileupload] Form params from the request command line?
In-Reply-To: <16d6c6200604041956k14a4d76ax3cd4f43f0e4e3a3c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_11722_17119541.1144207277316"
References: <44330FF2.1000605@computer.org> <44331161.1030200@schliesing.de>
	 <44331F65.9040302@webperformance.com>
	 <f8b39ace0604041856l66d232b2i578bec0bbe7e7187@mail.gmail.com>
	 <16d6c6200604041956k14a4d76ax3cd4f43f0e4e3a3c@mail.gmail.com>

------=_Part_11722_17119541.1144207277316
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 4/4/06, Martin Cooper <martinc@apache.org> wrote:
>
> On 4/4/06, Craig McClanahan <craigmcc@apache.org> wrote:
> >
> > On 4/4/06, Christopher L Merrill <chris@webperformance.com> wrote:
> > >
> > > Sven Schliesing wrote:
> > > > I know that this is a direct answer to your question, but why do yo=
u
> > mix
> > > > GET-params to a POST-Request? I'm not pretty sure if this is even
> > > > supported in the HTTP 1.1-standard.
> > >
> > > I am fairly certain there is no limitation against this usage in the
> > HTTP
> > > spec. If it's there, someone please point me to it...I'd like to see
> it.
> > >
> > > We find this particular case used quite frequently by our
> customers.  In
> > > fact, I'm looking at one of those customer sites right now - and it
> has
> > a
> > > mix of both in the login form.
> >
> >
> > In the Java arena the Servlet spec has explicit provisions describing
> how
> > this scenario (combination of query parameters on the URL and post data
> > parameters) is handled, and it's supported in a well-defined
> manner.  See
> > section SRV.4.1 of the servlet spec.
>
>
> Well, yes and no. The spec does state how the combination should be
> handled,
> but it then goes on to state that POST data is only available if it's
> application/x-www-form-urlencoded data. In fact, it is not possible to
> implement the spec to the letter for other types of POST data unless the
> container provides support for those other types. That's because there's
> no
> way (short of an explicitly configured servlet filter) for an external
> component such as Commons FileUpload to combine the POST parameters and
> the
> query parameters and present that combination to the user via the servlet
> API.


Agreed that the current FileUpload implementation doesn't violate the
servlet spec (which only deals with application/x-www-form-urlencoded), but
it would sure be cool if we could have Commons FileUpload simulate that mix
of query parameters from the URL and posted content from a
multipart/form-data post so that applications would be able to not worry
about the differences.  If it takes a filter and a request wrapper to do
that, so be it.  For me, the fact that filters require Servlet 2.3 or later
is not an issue (although it might be for others).

Technically, that's a bug in the spec, although I'll concede it's a minor
> one. ;-) On the other hand, why the Servlet EG has never yet baked in
> support for other types of POST content baffles me. Even a hook so that
> content type handlers can register with the container (and thus be able t=
o
> follow the spec to the letter in this regard) would be a great leap
> forward.


The servlet spec lacks a whole *ton* of things that it really needs to
address :-(.  I've got a half-completed blog entry on that topic that I hop=
e
to publish someday, now that I'm actually not flying on airplanes for two
weeks in a row.  But after that, life gets crazy again, so no guarantees.

--
> Martin Cooper


Craig

------=_Part_11722_17119541.1144207277316--