You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "HEBBRON,TOM (HP-UnitedKingdom,ex2)" <to...@hp.com> on 2001/08/01 11:56:09 UTC
Strange bug - XSLT filter on Tomcat 4.0 b6
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.
The code I am using is published at the above URL.
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?
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
RE: Strange bug - XSLT filter on Tomcat 4.0 b6
Posted by Stuart Halloway <st...@develop.com>.
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
Re: Strange bug - XSLT filter on Tomcat 4.0 b6
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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