вт, 24 мар. 2026 г. в 12:13, Mark Thomas <[email protected]>: > > 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().
I see a problem. It is easy to implement removeQueryParameters() to remove either "&" or "&", but a problem is with the subsequent addNonce() call. If the original URL had more than one parameter then you can detect whether it used "&" or "%amp;", and use the same. But if it had a single parameter then there is no way to decide what delimiter should be used. If you decide to implement this feature, please make it configurable. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
