• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Strange behaviour of HttpServletResponse.encodeURL()

 
chandan kumar mitwaa
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Context-Root: SessionUsingURLRewriting

JSPs : index.jsp, nonexistent.jsp(does not exist)
Servlets : Sessions, Servlet1
Tested on : Mozilla Firefox 3.5 with cookies disabled


web.xml




Sessions.java




Outputs
On Apache tomcat 6 (http://localhost:8080/SessionUsingURLRewriting/servlet/Sessions):


Encoded 1: /index.jsp
Encoded 2: /SessionUsingURLRewriting/index.jsp;jsessionid=D909F5D49FC0D6FC270307EDE81370C6
Encoded 3: http://localhost:8080/SessionUsingURLRewriting/index.jsp;jsessionid=D909F5D49FC0D6FC270307EDE81370C6
Encoded 4: ./../index.jsp;jsessionid=D909F5D49FC0D6FC270307EDE81370C6
Encoded 5: Servlet1;jsessionid=D909F5D49FC0D6FC270307EDE81370C6
Encoded 6: Servlet1;jsessionid=D909F5D49FC0D6FC270307EDE81370C6
Encoded 7: /servlet/Servlet1
Encoded 8: servlet/Servlet1;jsessionid=D909F5D49FC0D6FC270307EDE81370C6
Encoded 9: nonexistent.jsp;jsessionid=D909F5D49FC0D6FC270307EDE81370C6
Encoded 10: /nonexistent.jsp
Encoded 11: /nondir/nonexistent.jsp
Encoded 12: nondir/nonexistent.jsp;jsessionid=D909F5D49FC0D6FC270307EDE81370C6
Encoded 13: /SessionUsingURLRewriting/nondir/nonexistent.jsp;jsessionid=D909F5D49FC0D6FC270307EDE81370C6


On Glassfish v2(http://localhost:8086/SessionUsingURLRewriting/servlet/Sessions):


Encoded 1: /index.jsp
Encoded 2: /SessionUsingURLRewriting/index.jsp;jsessionid=dea4eecc26abc056114b0f2eb92a
Encoded 3: http://localhost:8080/SessionUsingURLRewriting/index.jsp
Encoded 4: ./../index.jsp;jsessionid=dea4eecc26abc056114b0f2eb92a
Encoded 5: Servlet1;jsessionid=dea4eecc26abc056114b0f2eb92a
Encoded 6: Servlet1;jsessionid=dea4eecc26abc056114b0f2eb92a
Encoded 7: /servlet/Servlet1
Encoded 8: servlet/Servlet1;jsessionid=dea4eecc26abc056114b0f2eb92a
Encoded 9: nonexistent.jsp;jsessionid=dea4eecc26abc056114b0f2eb92a
Encoded 10: /nonexistent.jsp
Encoded 11: /nondir/nonexistent.jsp
Encoded 12: nondir/nonexistent.jsp;jsessionid=dea4eecc26abc056114b0f2eb92a
Encoded 13: /SessionUsingURLRewriting/nondir/nonexistent.jsp;jsessionid=dea4eecc26abc056114b0f2eb92a


Can anyone explain me why the above behaviour is observed? Can we frame a rule for the paramete type passed to HttpServletResponse.encodeURL() and its observes return value?

Why is there a difference in the outputs observed for the two containers in Encoded3?
 
Tomasz Szymanski
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you think of it - a URL needs to be rewritten only when it is pointing back to the same application, right? There's no point in passing a session ID to any other application (in fact - it might be insecure).
That's why there's no session ID your 1, 7, 10 and 11 URLs - they all begin with a slash followed by something different than SessionUsingURLRewriting.

I'm not sure why there's a difference in Encoded3. Probably because it is a complete URL, containing the protocol, which seems to be misleading for Glassfish, as it is actually pointing to the same web app.

Anyway - an interesting experiment ;-)
 
chandan kumar mitwaa
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Tomasz


When you think of it - a URL needs to be rewritten only when it is pointing back to the same application, right? There's no point in passing a session ID to any other application (in fact - it might be insecure).


I have added this line as the last line in my code:




And both the containers are giving me the output:

Encoded 14: /SessionUsingURLRewriting/../nondir/nonexistent.jsp;jsessionid=ebab003123420dc7494140ed08c7



I don't think that the url is still pointing to the same application.
What do you say???
 
Tomasz Szymanski
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting again :-) I would say it is a small imperfection of those containers... You fooled them.
Obviously the algorithm for deciding whether a URL should be "encoded" is simple: encode if it's relative (doesn't start with "/") or, in case it's absolute, the beginning is equal to the current context. That's just my guess.

But that kind of URL (the 14th) is kind of "broken", isn't it? I mean I can't imagine a case where you would generate it by design. So maybe it wasn't considered as a big deal by the container authors...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic