commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mfncoo...@gmail.com>
Subject Re: [FileUpload] Issue with multipart/form-data and request parameters in include
Date Thu, 01 Sep 2005 23:45:57 GMT
On 8/28/05, Andreas Schildbach <andreas@schildbach.de> wrote:
> 
> Hello Brian,
> 
> I am sorry my last answer was a bit sloppy. For the sake of simplicity,
> please consider the following JSP 2.0 fragment:
> 
> --- fragment.jsp ---
> ${param.p}
> --- end fragment.jsp ---
> 
> This obviously outputs the parameter named p. Of course, my real
> fragment is much more complex than that, using an own controller and
> such (I was also using the words "plugin" and "portlet" because
> web-designers often use these. I was not talking about applets or
> embedded objects).
> 
> Ok, now here is a JSP which is the target of a form (I am skipping
> taglib defs):
> 
> --- target.jsp ---
> <c:import url="fragment.jsp?p=value1"/>
> hello world
> <c:import url="fragment.jsp?p=value2"/>
> --- end target.jsp ---
> 
> --- form.jsp ---
> <form action="target.jsp" method="post" enctype="multipart/form-data">
> [skipping form fields]
> </form>
> --- end form.jsp ---
> 
> (and yes, I did get jsp:include and c:import mixed up in my last post)
> 
> Now, here is what happens with the different methods for posting the form:
> 
> 1. GET: "value1 hello world value2"
> 2. POST (default enctype): "value1 hello world value2"


These are the only two combinations for which the container is required to 
make parameters available. See SectionSRV.4.1.1 of the Servlet 2.3 spec.

3. POST enctype="multipart/form-data": "hello world"


The container will not parse this (which is why you need Commons FileUpload 
in the first place), so the parameters are not being seen.

The thing to remember here is that the HTTP method and content encoding are 
preserved for request dispatcher calls within a request. That means that, 
since you submitted your form using #3 above, that same method and encoding 
will be used for the two <c:import>s, since those are implemented as request 
dispatcher includes.

As I wrote, I am wondering why 2 works but I am very happy about it. It
> would be great if 3 worked as 2.
> 
> I wonder what would be a reliable way to add parameters to included
> resources, that works regardless of the type of initial request.


Use request attributes instead of request parameters.

--
Martin Cooper


I am using FileUpload in a Spring
(springframework.org<http://springframework.org>)
> context, in a
> way that can be compared to a Servlet filter:
> 
> <bean id="multipartResolver"
> class="org.springframework.web.multipart.commons.CommonsMultipartResolver
> "/>
> 
> I hope I left no questions open this time. Sorry for that last
> inaccurate post.
> 
> Regards,
> 
> Andreas
> 
> 
> ---------------------------------------------------------------------
> 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