[richfaces-issues] [JBoss JIRA] Commented: (RF-1360) BaseFilter fails to recognize non-faces resource requests, invoking BaseXMLFilter.doXmlFilter()
Stuart Robertson (JIRA)
jira-events at lists.jboss.org
Thu Nov 15 15:27:18 EST 2007
[ http://jira.jboss.com/jira/browse/RF-1360?page=comments#action_12387816 ]
Stuart Robertson commented on RF-1360:
--------------------------------------
Oh, one more thing that may be helpful. The generated debug output that I included comes from a modification I made to the SeamFilter. You may find this useful as well, but either way it explains the output I sent along:
...my SeamFilter changes:
public void doFilter(ServletRequest request, ServletResponse origResponse)
throws IOException, ServletException
{
HttpServletResponseWrapper response = new HttpServletResponseWrapper((HttpServletResponse)origResponse) {
@Override
public void setContentType(String contentType) {
super.setContentType(contentType);
Exception e = new Exception("contentType set to " + contentType);
// log.warn("setContentType of #0 called. Caller stacktrace follows", e);
e.printStackTrace();
}
};
This basically shows who is calling setContentType, and the value it's being set to.
> BaseFilter fails to recognize non-faces resource requests, invoking BaseXMLFilter.doXmlFilter()
> -----------------------------------------------------------------------------------------------
>
> Key: RF-1360
> URL: http://jira.jboss.com/jira/browse/RF-1360
> Project: RichFaces
> Issue Type: Bug
> Environment: Richfaces 3.1.3 (cvs), Seam 2.0.1 (cvs), Jboss 4.2.2
> Reporter: Stuart Robertson
> Priority: Critical
> Fix For: 3.1.3
>
>
> When servicing a non-jsf request, in this case to stream a pdf down to the user, the BaseFilter is mangling the contentType by appending an incorrect char encoding onto the (correct) content type.
> 13:58:28,313 INFO [FileServlet] Streaming file About Stu.pdf, contentType application/pdf and size 94171 to browser...
> 13:58:28,371 ERROR [STDERR] java.lang.Exception: contentType set to application/pdf;charset=ISO-8859-1
> 13:58:28,371 ERROR [STDERR] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl$1.setContentType(SeamFilter.java:66)
> 13:58:28,371 ERROR [STDERR] at javax.servlet.ServletResponseWrapper.setContentType(ServletResponseWrapper.java:130)
> 13:58:28,371 ERROR [STDERR] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl$1.setContentType(SeamFilter.java:65)
> 13:58:28,371 ERROR [STDERR] at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:260)
> 13:58:28,371 ERROR [STDERR] at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
> 13:58:28,371 ERROR [STDERR] at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
> And in BaseFilter, doXmlFilter is always invoked because the if condition is for "true". Here is the code from BaseFilter starting on line 271:
> // check ajax request parameter
> // TODO - check for JSF page.
> if (true) {
> if (log.isDebugEnabled()) {
> log.debug(Messages
> .getMessage(Messages.FILTER_XML_OUTPUT));
> }
> // Execute the rest of the filter chain, including the
> // JSP
> xmlFilter.doXmlFilter(chain, httpServletRequest,
> httpServletResponse);
> doXmlFilter() appends an incorrect charType to a resource mimetype (in this case "application/pdf"). The correct behavior, if I read the code correctly, would be to invoke chain.doFilter() for resource requests.
> I think the key is in the TODO. The code needs to recognize when the request is outside of faces, and not interfere with the response headers at that point.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the richfaces-issues
mailing list