Hi Konstantin, Jeremy,
Yes I can provide a simple example shortly...
Apologies for breaking the first rule of questioning: provide all
details about operating system, container, libraries, etc.
Would it be best if I continue this discussion here or at Jira?
On 17-02-15 17:23, Jeremy Boynes wrote:
On Feb 17, 2015, at 4:34 AM, Konstantin Kolinko
<knst.koli...@gmail.com> wrote:
>
> 2015-02-14 20:04 GMT+03:00 Stephan van Loendersloot (LIST)
> <step...@republika.nl>:
>> Hi everyone,
>>
>> I have a question about this issue:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=37466
>>
>> I tried to switch to the latest Tomcat TagLibs implementation, but
due to
>> this fixed bug, it seems that posted form parameters aren't visible
anymore
>> in relative pages imported by <c:import> tags.
>>
>> The JSTl specicication 1.2, Section 7.2 (page 57) states that
relative URLs
>> should be processed in the exact same way as the include action of
the JSP
>> specification (<jsp:include>) when used in the same application
context.
>>
>> The older, Jakarta TagLibs don't have this problem, but the Tomcat
TagLibs
>> do...
>>
>> Can anyone tell me if the fix breaks the specification guidelines,
or did I
>> misread the whole thing?
>>
>
>
> BZ 37466 fix (r495005) was committed 8 years ago.
>
> You need to provide an example that reproduces your issue. Wrapping a
> request with overwritten getMethod() should not break parsing of POST
> parameters. The parameters parsing is done by tomcat internals and
> operates on the original request, not on the wrapper.
I think there may be an issue here but would like an example to
confirm. This change was introduced between 1.1 and 1.2 and after
GlassFish forked away.
The original thread that led to BZ 37466 related to HEAD requests
where the original HttpServletRequest was being passed to a
RequestDispatcher. What I took from the thread is that this would
result an empty response from the imported resource which the
application was not expecting - it tried to parse empty content and
failed. The r495005 patch attempts to fix this by forcing the method
to GET, mirroring the semantic of an external absolute URL where the
JSTL spec mandates a GET request is made when using HTTP.
I’m not convinced this change was correct. For relative URLs it
specifies the “whole environment is available … as well as request
parameters” and by forcing the method to GET we are indicating that
there is no request body to parse and so parameters in the original
POST body should be skipped. As Konstantin said, Tomcat does not take
account of wrappers so will still extract parameters from the request
body but that may not be true for other containers or if the
application code is parsing the request content.
Perhaps the issue here is actually with Tomcat’s implementation of
HttpServlet and/or DefaultServlet where it appears doHead() never
returns content even for dispatched includes. If these only suppressed
content for the original response but did return content for included
responses then BZ 37466 would not be an issue. This would also seem to
be necessary to return the same headers for HEAD as GET e.g. ensuring
that the Content-Length returned included bytes from the included
resource.
Stephan, please can you submit an example showing what’s failing for
you and include info on which container you are using and what version
of taglibs you are upgrading from.
Thanks
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
