On 23/03/2026 22:05, Christopher Schultz wrote:
Mark,
On 3/3/26 10:00 AM, Christopher Schultz wrote:
Mark,
On 2/25/26 4:23 AM, Mark Thomas wrote:
<snip/>
I disagree.
Something LinkTool ? is confusing HTML encoding and URL encoding.
A literal & is encoded as & in HTML (and XML).
A literal & is encoded as %26 if it needs to be encoded in a URI.
I think you need to get to the bottom of why a URI is being encoded
using HTML encoding and fix that. Once that has been addressed then
you can look at the URI and see if any further work is required.
Yes, I'm using LinkTool. I honestly think the problem is probably there.
LinkTool uses a fluent API (ugh) and any time you convert the object
to a String, it will use & because it's intended to be used for
generating links in HTML.
We have a use case where we need to create a LinkTool object and re-
use it for a lot of links based upon a single root link (this use case
is a pager, where the only thing that changes is a parameter or two).
I think the issue is when we parse a URL string, it's not reversing
its own process of & -> &.
So either LinkTool needs to change, or I need to massage the strings
passed-into it for that purpose.
This is not the issue.
The problem is that LinkTool's toString implementation looks like this:
public String toString() {
String str = super.toString();
return str.length() == 0 ? str : this.response.encodeURL(str);
}
The super.toString() call is what generates the entire URL from all the
other components. It's sensitive to its "xhtml" configuration flag and,
when that's set to "true", it will generate parameter delimiters as
"&" instead of "&".
I believe there are only a few options here:
1. Stop using XHTML=true in Velocity Tools
2. Change Tomcat to allow the use of &-separated parameters
3. Modify LinkTool to stop calling response.encodeURL
I believe that Velocity Tools's implementation of XHTML-formatted URLs
is simply incompatible with Tomcat's implementation of CSRF parameter
handling.
This doesn't happen elsewhere in Tomcat because jsessionid is the only
other similar operation we perform, and the ; doesn't need any special
handling in XHTML.
I'd like to reconsider whether & should be supported, here. It's not
absolutely clear what SHOULD be done, here, but I'd like to continue the
conversation a little to see what we can come up with.
If & is NOT supported, here, then applications wanting to generate
&-separated URLs will have to:
1. Generate a URL
2. Run it through response.encodeURL
3. Post-process one more time to swap & -> &
To remove LinkTool from the conversation we could compare to how this
would need to be done using JSTL:
<c:url var="myUrl" value="/products">
<c:param name="id" value="123" />
<c:param name="category" value="books & electronics" />
</c:url>
<a href="${myUrl}">View Product</a>
To get XHTML semantics, the application would need to change the final
line to this:
<a href="<c:out value='${myUrl}' />">View Product</a>
That's fine for a single page, but doing it for the entire application
isn't practical. The application can use .jspx and I think it will use
& but that happens in the XML serializer at the very end of the
whole process.
I think Velocity Tools has just decided to handle that conversion
because there is no JSPX-style post-conversion process available to it.
I could somewhat easily be convinced that "generating URLs in a page
with & delimiters is an experiment that failed, and we should forget
that it ever happened."
You have convinced me.
I withdraw my objection to handling "&" as equivalent to "&" in
encodeURL() and encodeRedirectURL().
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
