Hi Mike, I did see your idea, and thinking about it again now it could work quite well alongside the fix that claude proposed.
With your idea I don't think you'd want to remove the filters completely given that the master server being proxied to might be on an older version and ignore a new path filter header. However, I think you'd still want filtering on the request side of the proxy. Having the master server filter using a client provided string (on a path it will read/write) seems like a security nightmare. Also it wouldn't work for path based authorisation. With the claude fix of more selective filtering on the request side there is in theory no potential for user data munging anymore. For the response filtering I think your idea of passing a filter URL in the header to the master server side so it can do the filtering on the structured data could work well. There's little security concern because it would only be filtering data that is already on its way out, and we can hopefully resolve the last remaining edge cases for data munging. The only clash from the 2 fixes is that if the master server handles the filtering, we shouldn't filter on the response side. This is fine if the master server runs the same version and supports server-side filtering. But I think we'd need to selectively enable the response-side filtering if it's from an older master server that isn't performing any filtering. I don't know how big of a task it would be to do the master server-side filtering using a new header. I imagine it's a reasonable amount of work, but I think it's a better option than the other potential fix, performing full XML parsing and filtering on the proxy. If we want it to be free of edge cases. Thanks, Jordan On Mon, 6 Jul 2026 at 18:28, C. Michael Pilato <[email protected]> wrote: > > On Sat, Jul 4, 2026 at 4:21 PM Jordan Peck <[email protected]> wrote: >> >> Hi Mike, >> I added a test for a property change containing the slave URL and it >> was silently rewritten to the master URL without errors. So this is >> the worst case, because it's silent data corruption. > > > Okay, so this is what I feared with issue SVN-3445. (Thanks for whipping up > these tests, by the way!) > > I notice that I (softly) proposed the following in that same issue[1]: > >> Have the slave server drop a header into the proxied request that the >> master >> looks for. The header tells the master server what the slave's >> "localpath" >> is. The master, upon seeing that header, then uses the slave's localpath >> instead of its own paths when generating responses. Is a header which can >> essentially cause a server to lie about its locations a bad/insecure >> thing? > > > ... but I don't see any serious discussion about it in the issue itself. The > idea here being (if I can try to tap into my 17-years-ago-headstate...) that > as the slave proxies a request through to the master, it tells the master > "pretend, while generating protocol paths in your responses, that you're me". > I think that with such a setup, we don't need the content filters at all? > > -- Mike > > [1] > https://issues.apache.org/jira/browse/SVN-3445?focusedCommentId=14928254&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14928254
