I have 2 questions regarding URL rewriting and need your help.
First question is: What is the difference between HttpServletResponse.encodeURL() and HttpServletResponse.encodeRedirectURL(), apart from the fact that 1 is used for encoding a URL for redirect and the other is for any other purposes? Why is there a distinction between them, when both are just appending 'jsessionid' to the URL. Isn't HttpServletResponse.encodeURL()is sufficient for use with encoding of redirect URLs?
Second question is: Why are HttpServletResponse.encodeURL() and HttpServletResponse.encodeRedirectURL() methods of HttpServletResponse, and not HttpServletResquest? Since the jsessionid is obtained from either cookie or the rewritten URL, and they are part of request, shouldn't both encoding methods be in HttpServletResquest instead? Isn't this more OO?
The API says: The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL. Because the rules for making this determination can differ from those used to decide whether to encode a normal link, this method is separated from the encodeURL method.. Well, this does not tell us what those rules are, does it ? It looks like it has something to do with empty String urls. But the reason behind it is not clear. (see here).
Why are HttpServletResponse.encodeURL() and HttpServletResponse.encodeRedirectURL() methods of HttpServletResponse, and not HttpServletResquest?
encodeRedirectURL is meant to be used with HttpServletResponse.sendRedirect, so I think it doesn't hurt to have it it HttpServletResponse. Moreover, from the Servlet's point of view, these methods are used before sending a responspe back to the client. So in both case, I don't see why they should be in the HttpServletRequest.
Hi, I'm the guy that wrote the lengthy article that Christophe's "see here" points to. The exact difference between the two methods is still no clearer to me, it still looks very vague. You're not the only one puzzled by it!
I suspect whoever wrote the Javadoc might have had some very specific issue or situation in mind (possibly some gnarly detail of the W3C specs and how URLs are interpreted), but we're left just trying to guess what it might have been, and we're probably all wrong.
But unless you're trying to implement the API, I think all you need to worry about is making sure that you use the right method for each URL based on its purpose. I'd regard the result of these methods as opaque strings, whose precise details aren't entirely pinned down by the Javadoc but instead depend on mysterious, unspecified internals within each servlet container - and may be different for the two methods.
As for why these methods are on the response rather than the request, I think that's reasonable because they are adjusting values that are being put into the response. And whilst the session ID might have come in as part of the request, it could also be a new session created during the processing of this request and response. Also, any returning of the session ID to the client (to continue the session) mus t be part of the response, so the response does need to "know" the session ID anyway.
I think there is a more general issue that the request and response are inter-dependent in somewhat subtle and awkward ways - with response methods that can depend on details of the request; session-handling methods in the request that can depend on whether the response is committed yet; and session-handling methods in the request but with the response needing to use the session ID as well (e.g. for encodeURL). At the same time there's no explicit relationship between request and response instances, just a general notion that one request and one response are being processed together (e.g. in the HttpServletResponse Javadoc, what instance does "THE request" actually refer to?). So the split between request and response seems far from perfect, and I dare say it might be done rather differently if starting from scratch, but for now it's what we're stuck with.
[ March 17, 2008: Message edited by: Mike Kaufman ] [ March 17, 2008: Message edited by: Mike Kaufman ]
posted 12 years ago
Hi Christophe and Mike,
Thanks a lot for the explanations! I have benefited from them.