RFC-2047 Header Character Set Encoding JK + Tomcat 5

["Guernsey, Byron (GE Consumer & Industrial)" <BY...@GE.COM>]

Is there a FAQ on how Tomcat 5 and JK1 implement HTTP header character
sets? (ie, does it support RFC-2047)

We use some single sign-on plugin's at the web server (apache 2) that
set specific headers which may contain international characters.  The
headers are being returned by Tomcat to jsps/servlets in such a way that
the strings decode properly only if the browser is forced to view them
as UTF-8. 

This implies that the values are actually UTF-8 encoded, but improperly
assumed to be ISO-8859-1 as some point.

I have not yet tracked down which component in the chain is at fault. It
may very well be that the SSO plugin is calling the Apache API to set
Headers with UTF-8 values when they accept only ISO-8859-1 values, or
values encoded per RFC-2047.

I'd like to find out what mod_jk expects the header values to be when it
retrieves them from Apache, and whether Tomcat supports RFC-2047
decoding of header values.

If anyone has any experience with this, or can refer me to a discussion
or thread about this very item, I'd greatly appreciate the tip.  I'm not
looking forward to the amount of inspection I'm going to have to do to
find the culprit.

thanks,
Byron


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

Re: RFC-2047 Header Character Set Encoding JK + Tomcat 5

[Tim Funk <fu...@joedog.org>]

You may need to add this to your Connector declaration:
URIEncoding="UTF-8"

-Tim

Guernsey, Byron (GE Consumer & Industrial) wrote:

> Is there a FAQ on how Tomcat 5 and JK1 implement HTTP header character
> sets? (ie, does it support RFC-2047)
> 
> We use some single sign-on plugin's at the web server (apache 2) that
> set specific headers which may contain international characters.  The
> headers are being returned by Tomcat to jsps/servlets in such a way that
> the strings decode properly only if the browser is forced to view them
> as UTF-8. 
> 
> This implies that the values are actually UTF-8 encoded, but improperly
> assumed to be ISO-8859-1 as some point.
> 
> I have not yet tracked down which component in the chain is at fault. It
> may very well be that the SSO plugin is calling the Apache API to set
> Headers with UTF-8 values when they accept only ISO-8859-1 values, or
> values encoded per RFC-2047.
> 
> I'd like to find out what mod_jk expects the header values to be when it
> retrieves them from Apache, and whether Tomcat supports RFC-2047
> decoding of header values.
> 
> If anyone has any experience with this, or can refer me to a discussion
> or thread about this very item, I'd greatly appreciate the tip.  I'm not
> looking forward to the amount of inspection I'm going to have to do to
> find the culprit.
> 
> thanks,
> Byron
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org