RE: SVNIndexXSLT, server-side processing? [solution]

["M. van Renswoude" <ma...@x2software.net>]

> Try putting
> <xsl:output omit-xml-declaration="yes"/>
> in your xsl file, that should remove the XML PI.

That does the job for the XML declaration, thanks! Unfortunately, IE still
refuses to render it, and I have found out why: the Content-Type header is
text/xml. No Apache directive (such as 'Header') will solve that, so it's
time to hack the SubVersion source. As a note to the authors; I think
server-side XSLT processing is much nicer, and of course much more
compatible with older clients, so here's the suggestion for such a feature
:).


Here's what I did (based on the 1.0.4 source, compiled on Debian Sarge):

- Modify subversion/mod_dav_svn/repos.c, find:

----------------------------------------
  /* For a directory, we will send text/html or text/xml. If we have a delta
     base, then we will always be generating an svndiff.  Otherwise,
     we need to fetch the appropriate MIME type from the resource's
     properties (and use text/plain if it isn't there). */
  if (resource->collection)
    {
      if (resource->info->repos->xslt_uri)
        mimetype = "text/xml";
      else
        mimetype = "text/html; charset=UTF-8";
    }
----------------------------------------


then comment out the if-else to leave only text/html:


----------------------------------------
  if (resource->collection)
    {
      /*if (resource->info->repos->xslt_uri)
        mimetype = "text/xml";
      else*/
        mimetype = "text/html; charset=UTF-8";
    }
----------------------------------------


Assuming you already have it configured, go through the whole make clean /
make / make install cycle.

Now we need to process the XML output, for this I used xsltproc and a filter
written in Perl. I am planning to write an Apache 2 filter in C one day, but
my knowledge in that area is lacking at the moment so I'll just go for the
quick solution. Works fine for a quiet site.

First, the Perl script. Make sure it's executable by your webserver's user
of course. The source:


----------------------------------------
#!/usr/bin/perl
use strict;
use Digest::MD5 qw(md5_hex);

my @input       = <>;
my $input = join("\n", @input);

# Check for <svn> tag
if ($input =~ /<svn\s/)
{
  my $file;

  # Let XSLTProc process it
  # I have not found a satisfactory way to call xsltproc without
  # writing a file. Plenty of room for improvements, that's for sure...
  do
  {
    $file       = '/tmp/svn_' . md5_hex(localtime());
  } until (!-e $file);

  open (XML, ">$file");
  print XML $input;
  close (XML);

  system("xsltproc $file");
  unlink($file);
}
else
{
        # Just output it
        print @input;
}
----------------------------------------


Now we need to tell Apache to run it, here's my subversion virtual host:

----------------------------------------
<VirtualHost *:80>
  ExtFilterDefine svnxsl cmd="/web/subversion/xsltransform.pl"

  DAV svn
  SVNParentPath /var/lib/subversion/public
  SVNIndexXSLT "/web/subversion/svnindex.xsl"

  SetOutputFilter svnxsl
</VirtualHost>
----------------------------------------


I've left out all parts which aren't interesting (ServerName,
authentication, etc). One note here: SVNIndexXSLT is now an absolute path
instead of the old relative path. The reason for this is that xsltproc will
detect the stylesheet reference and apply it, which means we don't have to
provide the location on the command line. Makes it easier to apply different
stylesheets on different hosts...


So far this solution works like a charm.


- Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: SVNIndexXSLT, server-side processing? [solution]

[Mark <ma...@msdhub.com>]

Imagine that, IE does the right thing...

What with IE now respecting content-types AND being the only browser that
complies with the URI RFC (i.e. not allowing user:password@host for http
urls), maybe it's time for some of that life insurance...

Mark

-----Original Message-----
From: M. van Renswoude [mailto:mark@x2software.net] 
Sent: Friday, May 28, 2004 7:30 AM
To: users@subversion.tigris.org
Cc: Robert Koberg
Subject: RE: SVNIndexXSLT, server-side processing? [solution]

Either way, the real problem was the Content-Type: text/xml which caused IE
to render it as an XML tree even after the XHTML output was completely
valid, so that just needed the source change to text/html...

- Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: SVNIndexXSLT, server-side processing? [solution]

["M. van Renswoude" <ma...@x2software.net>]

> There might be another problem. Are you sure you have closing tags for
> things like <title/> and <script/>? If they are rendered closed then the
> page will not display. You need to force the close tag to show, E.g:

The XSL had <link href="/svnindex.css"/> in there, but due to the
output="html" setting it removed the last /. It did that with the <meta> tag
as well. I tried <link></link>, I even tried an <xsl:element> to build the
link tag that way, but the output remained the same. It treats those tags
differently it seems, because when I did <blah/> it outputted it correctly.

Either way, the real problem was the Content-Type: text/xml which caused IE
to render it as an XML tree even after the XHTML output was completely
valid, so that just needed the source change to text/html...


- Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: SVNIndexXSLT, server-side processing? [solution]

[Robert Koberg <ro...@koberg.com>]

M. van Renswoude wrote:

>>Try putting
>><xsl:output omit-xml-declaration="yes"/>
>>in your xsl file, that should remove the XML PI.
> 
> 
> That does the job for the XML declaration, thanks! Unfortunately, IE still
> refuses to render it, and I have found out why: the Content-Type header is
> text/xml. No Apache directive (such as 'Header') will solve that, so it's
> time to hack the SubVersion source. As a note to the authors; I think
> server-side XSLT processing is much nicer, and of course much more
> compatible with older clients, so here's the suggestion for such a feature
> :).

There might be another problem. Are you sure you have closing tags for 
things like <title/> and <script/>? If they are rendered closed then the 
page will not display. You need to force the close tag to show, E.g:

<title>something</title>
<script src="boo.js">//</script>

FWIW, another gotcha is textarea -- you need to force an end tag to 
render for that too.

best,
-Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org