You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2010/07/13 20:08:29 UTC
DO NOT REPLY [Bug 49591] New: Custom error page always uses
Transfer-Encoding: chunked
https://issues.apache.org/bugzilla/show_bug.cgi?id=49591
Summary: Custom error page always uses Transfer-Encoding:
chunked
Product: Tomcat 7
Version: 7.0.0
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: enhancement
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: kmoon@autonomy.com
Created an attachment (id=25759)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25759)
Small JSP which should easily fit in the output buffer.
When using a small custom error JSP page (which easily fits in the output
buffer, and so would not usually require chunking), error responses always use
chunked encoding, while non-error responses do not.
For example, visiting a missing resource (resulting in a 404) serves the error
page as chunked, while visiting the error page directly (resulting in a 200)
serves the error page without chunking.
Static resources are always served unchunked.
I would like to request that a custom error JSP is not served chunked if it
fits entirely within the output buffer, just like a regular JSP would. While
not a bug, I like to avoid chunked encoding (and the extra flushes involved)
whenever possible.
I initially encountered this issue in 6.0.24, but verified it is still present
in 7.0.0, and the source code seems unchanged in the trunk.
To replicate this issue, I modified the ROOT webapp of a fresh 7.0.0 install as
follows:
1. I added these lines to webapps/ROOT/WEB-INF/web.xml:
<error-page>
<error-code>404</error-code>
<location>/404.jsp</location>
</error-page>
2. I added the attached 404.jsp to webapps/ROOT/.
3. I visited http://localhost:8080/404 and received a chunked response.
4. I visited http://localhost:8080/404.jsp and received an unchunked response.
Stepping through the code, I discovered that the issue seems to be caused by a
flushBuffers() call in
org.apache.catalina.core.StandardHostValve.status(Request, Response). The code
looks something like this:
if (custom(request, response, errorPage)) {
try {
response.flushBuffer();
} catch (ClientAbortException e) {
// Ignore
} catch (IOException e) {
container.getLogger().warn("Exception Processing " + errorPage, e);
}
}
A normal page doesn't flush buffers until finishResponse() occurs, at which
point it can decide to set the content length or use chunked encoding. Flushing
earlier than that triggers chunked encoding (if possible).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 49591] Custom error page always uses
Transfer-Encoding: chunked
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49591
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #3 from Mark Thomas <ma...@apache.org> 2011-07-27 09:47:01 UTC ---
I agree with Tim.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 49591] Custom error page always uses
Transfer-Encoding: chunked
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49591
Tim Whittington <ti...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P5
--- Comment #1 from Tim Whittington <ti...@apache.org> 2010-09-23 07:13:23 EDT ---
The only way to fix this is to call Response.finishResponse() after sending of
the error page, or to remove the flushBuffer() call.
The former seems dubious, and the latter means that we wouldn't be flushing the
error response (headers and data) as soon as possible, which is probably
desirable.
Chunked encoding isn't itself an issue, so for the sake of optimising small
error pages I'm leaning towards WONTFIX on this one.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 49591] Custom error page always uses
Transfer-Encoding: chunked
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49591
--- Comment #2 from kmoon@autonomy.com 2010-09-23 12:33:12 EDT ---
Flushing the error response as soon as possible sounds desirable, but after
giving it some thought, the response still can't be flushed until the JSP has
flushed at least once (explicitly or due to end of page), in order to allow the
JSP to set headers (as required by the JSP specification: version 2.2, section
JSP 11.3, Buffering).
So in the case that the response is complete, flushing the headers immediately
is simply an extra flush (the data should already be in the buffer).
Agreed this isn't actually a problem, and doesn't need to be fixed. I just
think it would be nice. :-) I can see how it might get complicated, though.
To provide some context, the reason I initially reported this is because I ran
into an issue with Internet Explorer's "friendly error page" feature.
Internet Explorer will display a friendly error page if the error response body
is under a certain number of bytes (512 or so by default, I think). The
interesting part is that if the response body is chunked, it doesn't wait for
the entire response body to arrive; it decides as soon as it has any part of
the response body.
So if you have a very short first chunk, and the next chunk arrives in a later
network packet, it'll assume the response is actually under the limit, and
display the friendly error page. (However, it does combine chunks that arrive
in the same packets; I'm guessing it runs the check immediately after the first
read() or whatever.) This sorta makes sense, since a chunked response is
unbounded in size, although I'm still a bit dubious as to the rationale.
Anyway, this IE-specific behavior is easy enough to work around simply by
ensuring the first chunk is large enough. (My application was flushing very
frequently, resulting in lots of small chunks. The behavior was sensitive to
network latency, so it was a bit of pain to track down.) I just reported this
because I was surprised to still see a single chunk body for errors (but not
non-errors), even after I had eliminated all the explicit flushes.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 49591] Custom error page always uses
Transfer-Encoding: chunked
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49591
Tim Whittington <ti...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P5 |P4
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org