tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart Halloway" <stuthu...@develop.com>
Subject RE: Strange bug - XSLT filter on Tomcat 4.0 b6
Date Fri, 10 Aug 2001 18:01:59 GMT
Tom, Craig,

Thanks for pointing out the bug in the filter example on the JDC Tech Tips.
A fixed version of the tip will be up shortly.

Stuart Halloway
http://staff.develop.com/halloway


-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Wednesday, August 01, 2001 2:38 PM
To: 'tomcat-user@jakarta.apache.org'
Subject: Re: Strange bug - XSLT filter on Tomcat 4.0 b6




On Wed, 1 Aug 2001, HEBBRON,TOM (HP-UnitedKingdom,ex2) wrote:

>
> Hi - I've been writing an XSLT filter using the servlet 2.3 filter
> mechanism, and have come across this bug several times, including in the
> example xslt filter at suns JDC
>
(http://developer.java.sun.com/developer/JDCTechTips/2001/tt0626.html#tip2)
>
> Basically, if the size of the transformation result is greater than the
> source xml file size, the output will be truncated.
> So, if I serve index.xml (599bytes) using the filter, and an xsl file
which
> adds quite a lot of fancy html around the data from index.xml, I wil only
> get the first 599bytes of the output - although printing this output to
> System.out just after calling transformer.transform will yield the
complete
> result stream.
>

There is a corresponding problem if the transformed size is *smaller* than
the original size.  In that case, your filter will be writing fewer bytes
than the container expects.

It is your responsibility to call response.setContentLength() on the
"real" response in your filter if you change the content length of the
content provided by the original servlet.  The value your filter sets must
match the number of bytes your filter is actually going to write to the
"real" response's output stream.

> The code I am using is published at the above URL.
>

Looks like a bug in this code ... i'll send feedback to the author.

> I have also tried a couple of other example XSLT filters, and all of them
> have either come up with this error, or failed to work completely.
>
> Is this a problem with adding to the size of the servlet response - is it
a
> fixed size?
>

Without using filters, your servlet is responsible for settting the
"Content-Length" header of the response (normally this is done by calling
setContentLength()), and then writing exactly that many bytes.  If the
servlet does *not* set the content length explicitly, the container will
deal with it (for example, if you're using HTTP/1.1 persistent
connections, it will switch to chunked output mode).

However, if the servlet *did* set the content length of the response, and
a filter post-processes the response data to change the length, then it is
the filter's responsibility to update the content length on the
"real" response to match the number of bytes that it actually writes.

The filter code could be modified to do this.  It would involve capturing
the output of the transform into a ByteArrayOutputStream (or perhaps to a
temporary file if you're doing big transforms), counting the bytes,
calling response.setContentLength(), and then copying the bytes to the
response output stream.

> Thanks for any help/suggestions - I felt sure that someone else must have
> discovered this as well, but couldn't see anything on the web or mail
> archives.
>

> Tom Hebbron                             Tel: + 44 (0) 11731 29300
> hp BCO e-business                       Fax: + 44 (0) 11731 29923
> tom_hebbron@hp.com
>

Craig McClanahan



Mime
View raw message