[
http://issues.apache.org/jira/browse/GERONIMO-2192?page=comments#action_12447137
]
Nikla Ratinen commented on GERONIMO-2192:
-----------------------------------------
Hi,
I tested this quickly with Geronimo 1.1.1 + Jetty on port 8080, Apache 2 +
mod_jk 1.2.15 on port 80.
- The problem occurs *only* through AJP
- There are no stacktraces in the logs - Jetty just returns 404 Not Found for
existing resources
- Replacing
repository/jetty/org.mortbay.jetty/5.1.10/org.mortbay.jetty-5.1.10.jar with a
version
from Jetty 5.1.11 distribution fixes the problem
I'm sure there are more elegant ways to upgrade Jetty ;)
Repeating is slightly tedious due to need to setup Apache + mod_jk; however
here's
my simple 2 page setup. Disable cookies, then load index.jsp through AJP,
click on 'Page 2' link => 404 Not Found. Repeating the test through 8080
directly works fine.
------------ index.jsp ----------
<html>
<body>
<%
request.getSession(true);
%>
<a href="<%= response.encodeURL("page2.html") %>">Page 2</a><br/>
</body>
</html>
--------- page2.html --------
<html>
<body>
This is page 2
</body>
</html>
> Jetty can't handle encoded urls that contain a jsessionid
> ---------------------------------------------------------
>
> Key: GERONIMO-2192
> URL: http://issues.apache.org/jira/browse/GERONIMO-2192
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Affects Versions: 1.1
> Environment: Geronimo 1.1, Jetty version; Sun JDK 1.5_4, OpenSuSE
> 10.1, 712 MB RAM
> Reporter: D. Strauss
> Priority: Critical
>
> Hello,
> another testing here was to check if a webapp would still be usable when the
> user blocks any cookies from us. JEE typically uses a cookie named JSESSIONID
> (I think this is specified somewhere) to identify a user at a web request
> time. Now, if cookies are blocked, the developers are instructed to "encode"
> the urls using the HttpServletResponse.encode() method. Even the JSTL and
> c:url use this behaviour (fortunately :P).
> Anyway, today, Jetty had some problems when cookies are blocked. The urls are
> encoded at request time, so, a url like
> /register.jspx
> becomes
> /register.jspx;jsessionid=<long hexadecimal value>
> Using Tomcat, everything works as expected (i.e. the user gets identified as
> long as he/she uses the session identifier). Jetty, on the other hand, drops
> the request with a HTTP 404 error telling that it can't find a file named
> "register.jspx;jsessionid=<long value>". This is, of course, right. However,
> it's not the expected behaviour.
> Seems that Jetty can't figure out that this request is encoded ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
