Strange behaviour of HttpServletResponse.encodeURL()

[chandan kumar mitwaa]

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

   
<web-app>
....   
  <servlet>
    <servlet-name>Servlet1</servlet-name>
    <servlet-class>mit.Servlet1</servlet-class>
  </servlet>
  <servlet>
    <servlet-name>Sessions</servlet-name>
    <servlet-class>mit.Sessions</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>Servlet1</servlet-name>
    <url-pattern>/servlet/Servlet1</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>Sessions</servlet-name>
    <url-pattern>/servlet/Sessions</url-pattern>
  </servlet-mapping>
</web-app>

Sessions.java

 package mit;

import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class Sessions extends HttpServlet
{
	@Override
	public void doPost(HttpServletRequest request, HttpServletResponse response)
				throws ServletException, IOException
	{

		response.setContentType("text/html");
		PrintWriter out = response.getWriter();
		request.getSession();
		out.println("<br>Encoded 1: " + response.encodeURL("/index.jsp"));
		out.println("<br>Encoded 2: " + response.encodeURL("/SessionUsingURLRewriting/index.jsp"));
		out.println("<br>Encoded 3: "+ response.encodeURL("http://localhost:8080/SessionUsingURLRewriting/index.jsp"));
		out.println("<br>Encoded 4: " + response.encodeURL("./../index.jsp"));
		out.println("<br>Encoded 5: " + response.encodeURL("Servlet1"));
		out.println("<br>Encoded 6: " + response.encodeURL("Servlet1"));
		out.println("<br>Encoded 7: " + response.encodeURL("/servlet/Servlet1"));
		out.println("<br>Encoded 8: " + response.encodeURL("servlet/Servlet1"));
		out.println("<br>Encoded 9: " + response.encodeURL("nonexistent.jsp"));
		out.println("<br>Encoded 10: " + response.encodeURL("/nonexistent.jsp"));
		out.println("<br>Encoded 11: " + response.encodeURL("/nondir/nonexistent.jsp"));
		out.println("<br>Encoded 12: " + response.encodeURL("nondir/nonexistent.jsp"));
		out.println("<br>Encoded 13: " + response.encodeURL("/SessionUsingURLRewriting/nondir/nonexistent.jsp"));

		out.close();
	}

	@Override
	public void doGet(HttpServletRequest request, HttpServletResponse response)
				throws ServletException, IOException
	{
		doPost(request, response);
	}

}   

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]

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]

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:

out.println("<br>Encoded 14: "+ response.encodeURL("/SessionUsingURLRewriting/../nondir/nonexistent.jsp"));

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]

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...