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 02:56:18 GMT
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.

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.

--
Martin Cooper


The HTTP spec is silent on this issue, as it should be ... interpretation of
> URLs and content types is a layer above the HTTP protocol itself.
>
> Craig
>
>
> C
> >
> >
> > --
> > ------------------------------------------------------------------------
> -
> > Chris Merrill                           |  http://www.webperformance.com
> > Web Performance Inc.
> >
> > Website Load Testing and Stress Testing Software & Services
> > ------------------------------------------------------------------------
> -
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> >
>
>

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