Thank you so much for trying to help me. I did some thinking and now I'm
starting to blame the RequestDispatcher.  Could it be that some special
HttpServletResponse wrapper prevents servlet resources that are called
through the RequestDispatcher from setting content type on the parent? This
would fit with the rest of the facts:

- Works on Tomcat because it has a different RequestDispatcher
- Works when requesting a .jsp directly, since there is no forwarding

Is there any way to tell the RequestDispatcher to leave the contentType
BTW, we're using Resin 2.1.10 but have an option of upgrading to 3.0.19 if
the issue has been resolved in between those versions.

Regards, Misha

On 1/22/07, Scott Ferguson <[EMAIL PROTECTED]> wrote:

On Jan 21, 2007, at 9:07 PM, Michael Varshavsky wrote:

> Hi,
> I've received a request to convert a currently existing mobile
> Struts/Tiles-based web application to serve content as
> MimeMultipart instead of XHTML. I wrote a ServletFilter that
> captures all markup in the response, then parses it to find all the
> necessary (css and img) files and downloads them. After that I
> create a MimeMultipart object, add markup as a parent part and
> styles and images as regular MimeBodyPart(s). Then I set
> contentType of the response object to be that of the MimeMultipart
> (ends up being "multipart/related; boundary xxxxxxx"), write
> MimeMultipart to it and close. I developed and tested on my local
> Tocat installation and everything worked as expected. When we
> attempted to deploy the code onto our QA server that is running
> Resin, we ran into a problem. The filter executes fine, body parts
> are added as expected and the contentType is set correctly to
> "multipart/related" (prints fine in the Logs). However, when it
> gets to the client, the contentType is overwritten to be "text/
> html; charset=UTF-8". As a result, browser tries to interpret the
> Mutlipart as regular markup writing out binary data for images,
> etc. - which is obviously not the desired result.
> At first I thought this could be due to the fact that our jsps/
> tiles explicitly and through directives set the contentType
> to be "text/html". So I captured the markup from a regular page in
> the app, added
>       <%@ page language='java' session='true' contentType='text/
> html; charset=UTF-8'%>
>    <% response.setContentType("text/html; charset=UTF-8"); %>
> to it and saved it as jsp page outside of WEB-INF so that I can hit
> it directly. This worked fine on Resin!!! I then created a fake
> Struts action mapping (ForwardAction) which forwarded to a fake
> Tiles definition - which pointed to the same exact test jsp page
> (that worked). In this scenario the problem resurfaced and
> contentType got overwritten to "text/html".
> I started blaming Struts. Struts has a way to set contentType on a
> per-module basis, through controller's contentType attribute. I
> decided to check if that was the root of my problem, so I've added
> <controller contentType="text/plain"/> to my struts configuration
> hoping to see my contentType being overwritten to be "text/plain"
> instead of "text/html". However,
> the contentType header still got overwritten to be text/html.
> Trying to think what can possibly be downstream from my filter I
> became suspicious of Apache. However, even after disabling
>  mod_mime, the problem persisted!

To debug, you can open a Resin http port to 8080 to eliminate Apache
as a consideration (I doubt it's the cause.)

I'm not sure what's calling the extra setContentType, since it looks
like some kind of struts interaction.  Is it possible to reproduce
this with just forwards/includes and filters?

-- Scott

> At this point I don't know what to think and any help would be
> greatly appreciated!
> Thanks in advance!!!
> Misha.
> _______________________________________________
> resin-interest mailing list

resin-interest mailing list

resin-interest mailing list

Reply via email to