This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
I was under the impression that <c:url value="url_expression" /> not only did rewriting for urls not using the context attribute but also did url encoding most likely using HttpServletResponse.encodeURL() method. Am I wrong to think that encoding is done at all using <c:url .../>?
If it does encoding does it matter it there is a context attribute?
The JSTL 1.1 spec (link on this forum's links page) says that the url is not encoded by <c:url> tag. However, any params included as subtags will be if needed.
If the URL contains characters that should be encoded (e.g. space), it is the user's responsibility to encode them. ... <c:param> subtags can also be specified within the body of <c:url> for adding to the URL query string parameters, which will be properly encoded if necessary.
[ February 15, 2007: Message edited by: Carol Enderlin ]
Strange. It seems "encode" is an overloaded term here with two meanings. Never really thought about it before. One meaning: "fix the spaces and non-friendly url characters (what truly should be called encoding)" and the other: "add a session tracker if it's needed (aka URL rewriting)". I guess the encodeURL method should have been called rewriteURL instead.
My understanding was/is that c:url and response.encodeURL both rewrite (aka "encoding" by meaning 2). By what Carol found, it looks like c:params get encoded [non-safe characters] but the value of c:url does not.
I guess the programmer could extend the c:url with a custom taglib that would make a call to URLEncoder.encode or escapeXml seems like another interesting option. [ February 15, 2007: Message edited by: Marc Peabody ]