Attached is a patch that resolves the issue.
The problem is that the link to an RSS feed is created as a friendly url. For instance link to the blog feed will be mapped by the following entry in blogs-friendly-url-routes.xml
<route>
<pattern>/rss</pattern>
<implicit-parameter name="p_p_lifecycle">1</implicit-parameter>
<implicit-parameter name="p_p_state">exclusive</implicit-parameter>
<implicit-parameter name="struts_action">/blogs/rss</implicit-parameter>
</route>
This will result in a url that might look like http://localhost:8080/web/guest/home/-/blogs/rss
When this url is requested it passes through the StripFilter in which the following check will take place
protected boolean isStrip(HttpServletRequest request) {
....
if ((lifecycle.equals("1") && LiferayWindowState.isExclusive(request)) || lifecycle.equals("2"))
{
return false;
}
}
The check will return false because it cannot see the implicit parameters defined in the mapping. It will wrap the servletResponse in a StringServletResponse that effectively caches all output in memory
Then the FriendlyURLServlet kicks in, transforms the friendly url to something that looks like
/c/portal/layout?p_l_id=10426&p_p_state=exclusive&p_p_lifecycle=1&p_p_id=33&_33_struts_action=%2Fblogs%2Frss&p_p_mode=view
And does a forward
At this point the request will pass through the stripfilter again it does nothing because it already wrapped the response
The RSS action gets excuted, the feed is written to the response (wrapped by StripFilter in a StringServletResponse) and the correct content type is set.
and somewhere down the line LayoutAction is called and here we find the following line
if (response.isCommitted())
{
return null;
}
Had the response not been wrapped in a StringServletResponse this would have returned true, but since it is. it wont and request processing will continue. render_portlet.jsp and portlet.jsp will be invoked in various stages, each overwriting the correct mimetype with the one defined in the page directive of init.jsp
The solution I think is simple, don't let the stripfilter run for friendly urls, only let the filter see the rewritten friendly url. then it can correcly determine if a request should be excluded from stripping (like is the case with rss feeds).
Bug
Closed
Minor
In fact there is 3 problems.
1. There is 800 white line before <?xml ...?> tag => XML invalid
2. The setContenType method is called after the response stream has bean opened => bad content type
3. There is a comma a the end of the file => XML invalid