commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: [fileupload] Form params from the request command line?
Date Wed, 05 Apr 2006 03:31:55 GMT
On 4/4/06, Craig McClanahan <craigmcc@apache.org> wrote:
>
> 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
> you
> > > 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).


Yeah, I've actually got code in the wings that does that. It almost went
into FileUpload 1.1, but I just wasn't (and still am not) happy with the
configuration code, so I held it back. Most likely it will land up in
FileUpload 2.0, along with solutions for most of the outstanding enhancement
requests.

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
> to
> > 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
> hope
> 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.


Yeah, I know it's hardly the most prominent. ;-) I'll look forward to
reading what you have to say about it, but I won't hold my breath. ;-)

--
Martin Cooper


--
> > Martin Cooper
>
>
> Craig
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message