https://bz.apache.org/bugzilla/show_bug.cgi?id=62669
Bug ID: 62669
Summary: ResponseIncludeWrapper.getContentType() never returns
NULL and sets the field
Product: Tomcat 8
Version: 8.5.x-trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ----
Hello,
according to the documentation
org.apache.catalina.ssi.ResponseIncludeWrapper.getContentType() should return
NULL if the content type is not known. However a fallback to
"application/x-octet-stream" is implemented and it actually sets the content
type field of the object.
I had a quick look into the SVN repository and it seems this code was
introduced in or before 2006. Because this was 12 years ago and because I could
not find any report regarding this issue, I guess everyone else can work with
that and only the documentation needs to be adapted.
However I actually prefer to get NULL. First of all for me it is bad practice
to set a value in a getter (if it is not called "lazy..."). But let me try to
explain the real problem.
The control flow of SSIFilter is:
* ...
* Wrap the actual response with ResponseIncludeWrapper
* Continue and complete the filter chain
* Check the content type
* ...
The problem is when the filter chain is continued and completed, other filters
that get the content type from the response (ResponseIncludeWrapper) actually
change the content type of the response even though this is most likely NOT
what the other filters want to do. It happens by accident, just by calling
getContentType.
Also some filters rely on the fact that the getContentType returns NULL if it
is not known, in order to check if they should set it on their own. They never
set the content type because with the current implementation it always return a
value other than NULL.
Best regards,
Sven.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
