[ 
http://issues.apache.org/jira/browse/GERONIMO-2192?page=comments#action_12447134
 ] 
            
David Jencks commented on GERONIMO-2192:
----------------------------------------

There's a jetty 6 integration available in sandbox/javaee5.  First build 
geronimo, then build this ee5 stuff.  It's not well tested yet, but the 
webconsole and daytrader work on it.

I downloaded, untarred, and started the latest weekly 1.2 build with no 
problems.  Please supply more info on the user list about what you are 
experiencing.

I think this is likely to be a security problem rather than a jetty problem.  
Is there any more info such as a server side stack trace?  Can you supply any 
more info on how to reproduce this?  

In particular I suspect this is related to the fixes for GERONIMO-2295 and 
GERONIMO-2327

> 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

        

Reply via email to