Re: slow servlet filter for ByteArrayOutputStream response Wrapper
On 01/06/2010 03:53, Manny Mondeo wrote: Hi , I have written a filter that strips the response of some html tags. The filter is working and executing around 30milliseconds. The problem is that the request takes around 30 seconds to load this in a browser. The filter gets executed fast but the status bar in the browser does not complete and the page gets struck to about 25 seconds before the response comes and gets rendered. That usually means the content length header isn't set correctly. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: slow servlet filter for ByteArrayOutputStream response Wrapper
2010/6/1 Manny Mondeo manny...@yahoo.com: httpRes.setContentLength(content.toString().length()); Also, the above, or simplier content.length(), will give you the length measured in characters, but Content-Length must be the length measured in bytes. For a multi-byte charset such as UTF-8 those are certainly not the same. (Unless all your characters are 7-bit). httpRes.setContentType( text/html; charset=UTF-8 ) ; out.write(content); out.flush(); out.close(); } Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: slow servlet filter for ByteArrayOutputStream response Wrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 6/1/2010 5:41 AM, Konstantin Kolinko wrote: 2010/6/1 Manny Mondeo manny...@yahoo.com: httpRes.setContentLength(content.toString().length()); Also, the above, or simplier content.length(), will give you the length measured in characters, but Content-Length must be the length measured in bytes. For a multi-byte charset such as UTF-8 those are certainly not the same. (Unless all your characters are 7-bit). I would think that this would be the problem, except that charCount(utf8str) = byteCount(utf8Str), so the worst thing that could happen is that the Content-Length was too /short/, and the browser would either read everything anyway, or ignore the extra bytes. A too-long Content-Type can definitely cause a browser to stall. I like this error better as the cause: //PrintWriter out = httpRes.getWriter(); PrintWriter out = wrapp.getWriter(); Why wrapp.getWriter(); ?? Certainly writing to the buffered response and never to the actual response will not send any data to the browser. :( - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwFE/UACgkQ9CaO5/Lv0PDnYACgwCosffsg66HpD7f443xYhscx of4An00pZmi8lbb8Ef3PJO+9Kr+k7n87 =q0Fl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: slow servlet filter for ByteArrayOutputStream response Wrapper
2010/6/1 Christopher Schultz ch...@christopherschultz.net: On 6/1/2010 5:41 AM, Konstantin Kolinko wrote: 2010/6/1 Manny Mondeo manny...@yahoo.com: httpRes.setContentLength(content.toString().length()); Also, the above, or simplier content.length(), will give you the length measured in characters, but Content-Length must be the length measured in bytes. For a multi-byte charset such as UTF-8 those are certainly not the same. (Unless all your characters are 7-bit). I would think that this would be the problem, except that charCount(utf8str) = byteCount(utf8Str), so the worst thing that could happen is that the Content-Length was too /short/, and the browser would either read everything anyway, or ignore the extra bytes. A too-long Content-Type can definitely cause a browser to stall. There is such thing as o.a.coyote.http11.filters.IdentityOutputFilter. If contentLength is set it will prevent sending more than the stated number of bytes (discarding the rest of them). Thus, the data will be trimmed at any HTML construct, or even between bytes comprising a single multibyte character. That is how I read the code: someone should do a test run to be sure. I like this error better as the cause: //PrintWriter out = httpRes.getWriter(); PrintWriter out = wrapp.getWriter(); Why wrapp.getWriter(); ?? Certainly writing to the buffered response and never to the actual response will not send any data to the browser. :( Certainly. Or the code that was posted in not the one that was run. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: slow servlet filter for ByteArrayOutputStream response Wrapper
2010/6/1 Manny Mondeo manny...@yahoo.com:
Hi ,
I have written a filter that strips the response of some html tags.
The filter is working and executing around 30milliseconds.
How do you measure the time?
The problem is that the request takes around 30 seconds to load this in a
browser. The filter gets executed fast but the status bar in the browser does
not complete and the page gets struck to about 25 seconds before the response
comes and gets rendered.
Maybe it loads images, loads and executes javascript, or maybe your
HTML is invalid. Maybe you have a firewall that scans your traffic for
malware. Have you tried it with a different browser?
String content = new String(c);
The above line is wrong. Use some explicit encoding.
StringBuffer buffer = new StringBuffer();
java.lang.StringBuilder may be a bit faster (though it is unlikely
that you will notice).
//PrintWriter out = httpRes.getWriter();
PrintWriter out = wrapp.getWriter();
Why wrapp.getWriter(); ??
httpRes.setContentLength(content.toString().length());
httpRes.setContentType( text/html; charset=UTF-8 ) ;
You cannot set charset when you already called getWriter(). Move the
above line higher in the code.
public PrintWriter getWriter()
{
if (writer == null)
{
try
{
writer = new PrintWriter(new
OutputStreamWriter(outputStream, this.getCharacterEncoding()));
The above will throw an exception if outputStream is null.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
