https://issues.apache.org/bugzilla/show_bug.cgi?id=55305
Bug ID: 55305
Summary: DefaultServlet sets ContentType after opening stream
[COPY OF 19721]
Product: Tomcat 7
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Servlet & JSP API
Assignee: dev@tomcat.apache.org
Reporter: warren.cross...@mofokom.biz
Created attachment 30624
--> https://issues.apache.org/bugzilla/attachment.cgi?id=30624&action=edit
moves the content type code up several lines.
https://issues.apache.org/bugzilla/show_bug.cgi?id=19721
I am experimenting with an xslt processing instruction filter which is hampered
by this problem. Hence my involvement as a stakeholder.
I think the arguments given for wont fix by Remey in 2003 were and are no
longer valid (and in logical fact contradictory) He says the example is not
supposed to actually work, is not affected by this as a bug and then correctly
suggests that the convoluted workaround is invalid (which it actually is).
The fix is to move the content type code up a few lines in the DefaultServlet.
>From a fast gap analysis, there is very low impact on this fix.
I think the correct behaviour is typically the expected behaviour, which in
this case is for the ServletRequest to have a content type "associated" with it
(by the container) before the filter chain is invoked.
Without this fix it would imply that the workaround for any filter which is
only to process a given mime type would need to check the magic in the stream
and exclude for every request NOT required for processing. This is indeed
incorrect as Remey pointed out because checking the stream is non deterministic
as it can and will induce blocking and lead to a conflagration of pain and
suffering.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
