On 14 Jul 2026, at 14:51, C. Michael Pilato <[email protected]> wrote: > > On Tue, Jul 14, 2026 at 5:14 AM Thomas Åkesson <[email protected] > <mailto:[email protected]>> wrote: >> Hi, >> >> I was unable to find any discussion on this deprecation of XSLT in the >> browsers. >> >> https://developer.chrome.com/docs/web-platform/deprecating-xslt >> >> I suspect this deprecation will break the Subversion web ui (folder listing >> and Collection of Repositories) and the customization point for these UIs >> (SVNIndexXSLT). >> >> We use this XSLT extensively so I am interested if anyone has experimented >> with server-side transformation? > > This is unfortunate, but hopefully the situation isn't quite as bad as you > might think. > > IIRC, the XSLT variant of the mod_dav_svn directory listing feature is > entirely optional. When a GET request arrives aimed at a versioned > directory, if SVNIndexXSLT is set, an XML response referencing the template > is generated; but otherwise, an HTML response is still generated.
I verified that you remember correctly (using curl). It does return html when SVNIndexXSLT is not set. I was under the impression that it always used XSLT. During my verification, I also discovered that the XML response is hard to get when SVNIndexXSLT is not set. I am getting html even when sending 'Accept: application/xml' / 'Accept: text/xml'. I suspect SVNIndexXSLT must be set to a dummy value when attempting server side transformation. > So this deprecation might force admins to turn off the SVNIndexXSLT "flavor", > resulting in some ... undecorated directory listings. But at least I expect > the listings will still "work" (for the most basic of definitions of "work"). > > It does cause me to wonder though... Would a SVNIndexCSS feature be > interesting -- where we generate that HTML with quite a bit more structure > (divs, ids, etc.) and allow folks to point to a CSS file that at least > pretties it up? That would probably be sufficient for some, when the goal is to fix up the looks, while it is insufficient when the goal is to add actions etc in order to produce a full web interface. We are doing the latter and it is a vital feature to keep this interface on the true svn urls (not on a separate path on the server). I did some experimentation with server-side transformation and was successful with mod_ext_filter as described below. Do you have any input on whether this transformation needs to be guarded to execute only for specific requests? ExtFilterDefine svn-xslt mode=output \ intype=text/xml outtype=text/html \ cmd="/usr/bin/xsltproc /srv/cms/rweb/repos-web/view/repos.xsl -" # In the Subversion location: SetOutputFilter svn-xslt Thanks, Thomas Å.
