You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Vitaly Baranovsky <vi...@gmail.com> on 2007/11/22 18:01:58 UTC
Why jetspeed sometimes doesn't return charset in content-type of response?
Hi all!
Usually jetspeed returns "text/html;charset=UTF-8" in response. But
sometimes after restart of tomcat server it returns just "text/html"
for every response till a next restart.
I've digged into code and found in method CapabilityValve.invoke next
lines of code:
................
String encoding = request.getRequest().getCharacterEncoding();
................
if (encoding != null)
{
contentType.append("; charset=" + encoding);
}
................
So, it looks like request.getRequest().getCharacterEncoding() returns
null. Why can it be? How can I correct this error?
Thanks!
--
With best regards,
Vitaly Baranovsky
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Why jetspeed sometimes doesn't return charset in content-type
of response?
Posted by Dennis Dam <d....@hippo.nl>.
Can you be more specific ? What kind of pages are these? The encoding
for certain pages is consistently wrong and consistently correct for
others ? or is it total random behaviour?
Did you try the Tomcat coding configuration? Did it have any effect ?
Vitaly Baranovsky wrote:
> Thanks!
>
> Why request.getRequest().getCharacterEncoding() returns 'UTF-8'
> usually, but sometimes for some pages of portal it returns null?
>
> 2007/11/23, Dennis Dam <d....@hippo.nl>:
>
>> Hi Vitaly,
>>
>> I'm no expert on encoding, but will try to give some suggestions, the
>> way I see it :)
>>
>> If the encoding on the HttpServletRequest is null, Jetspeed will
>> retrieve the preferred mediatype (which contains the character encoding)
>> via the capabilities map in the database. This is done by getting the
>> preferred mimetype for the user agent, and mapping that mimetype to a
>> mediatype (= the preffered mediatype). This mediatype contains the
>> character encoding, which is set to UTF-8 by default afaik. The
>> character encoding contained in this mediatype is used as a fallback, in
>> case the encoding is not set on the HttpServletRequest (by the container
>> I guess).
>>
>> See this piece of code in CapabilityValveImpl:
>>
>> if (encoding == null)
>> {
>> if (mediaType != null && mediaType.getCharacterSet() != null)
>> {
>> encoding = mediaType.getCharacterSet();
>> }
>> }
>>
>> You can try to use remote debugging to see what's going on in
>> CapabilityValveImpl:
>>
>> * what's the incoming character encoding on the HttpServletRequest? Is
>> it null, an empty string or utf-8 ?
>> * is the loaded preferred mediatype correct, does it have UTF-8 encoding?
>>
>> If nothing else works, you can try to set the encoding on the
>> HttpServletRequest:
>>
>> * you can set the default server encoding to UTF-8 in your container
>> (Tomcat):
>> JAVA_OPTS="-Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8"
>>
>> * If that doesn't work, you can try to set the character encoding with a
>> servlet filter, although I have no idea if it is best practice to do so,
>> or even possible. Anybody else who knows?
>>
>> Dennis
>>
>> Vitaly Baranovsky wrote:
>>
>>> Hi all!
>>>
>>> Usually jetspeed returns "text/html;charset=UTF-8" in response. But
>>> sometimes after restart of tomcat server it returns just "text/html"
>>> for every response till a next restart.
>>>
>>> I've digged into code and found in method CapabilityValve.invoke next
>>> lines of code:
>>> ................
>>> String encoding = request.getRequest().getCharacterEncoding();
>>> ................
>>> if (encoding != null)
>>> {
>>> contentType.append("; charset=" + encoding);
>>> }
>>> ................
>>>
>>> So, it looks like request.getRequest().getCharacterEncoding() returns
>>> null. Why can it be? How can I correct this error?
>>>
>>> Thanks!
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Why jetspeed sometimes doesn't return charset in content-type of response?
Posted by Vitaly Baranovsky <vi...@gmail.com>.
Thanks!
Why request.getRequest().getCharacterEncoding() returns 'UTF-8'
usually, but sometimes for some pages of portal it returns null?
2007/11/23, Dennis Dam <d....@hippo.nl>:
> Hi Vitaly,
>
> I'm no expert on encoding, but will try to give some suggestions, the
> way I see it :)
>
> If the encoding on the HttpServletRequest is null, Jetspeed will
> retrieve the preferred mediatype (which contains the character encoding)
> via the capabilities map in the database. This is done by getting the
> preferred mimetype for the user agent, and mapping that mimetype to a
> mediatype (= the preffered mediatype). This mediatype contains the
> character encoding, which is set to UTF-8 by default afaik. The
> character encoding contained in this mediatype is used as a fallback, in
> case the encoding is not set on the HttpServletRequest (by the container
> I guess).
>
> See this piece of code in CapabilityValveImpl:
>
> if (encoding == null)
> {
> if (mediaType != null && mediaType.getCharacterSet() != null)
> {
> encoding = mediaType.getCharacterSet();
> }
> }
>
> You can try to use remote debugging to see what's going on in
> CapabilityValveImpl:
>
> * what's the incoming character encoding on the HttpServletRequest? Is
> it null, an empty string or utf-8 ?
> * is the loaded preferred mediatype correct, does it have UTF-8 encoding?
>
> If nothing else works, you can try to set the encoding on the
> HttpServletRequest:
>
> * you can set the default server encoding to UTF-8 in your container
> (Tomcat):
> JAVA_OPTS="-Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8"
>
> * If that doesn't work, you can try to set the character encoding with a
> servlet filter, although I have no idea if it is best practice to do so,
> or even possible. Anybody else who knows?
>
> Dennis
>
> Vitaly Baranovsky wrote:
> > Hi all!
> >
> > Usually jetspeed returns "text/html;charset=UTF-8" in response. But
> > sometimes after restart of tomcat server it returns just "text/html"
> > for every response till a next restart.
> >
> > I've digged into code and found in method CapabilityValve.invoke next
> > lines of code:
> > ................
> > String encoding = request.getRequest().getCharacterEncoding();
> > ................
> > if (encoding != null)
> > {
> > contentType.append("; charset=" + encoding);
> > }
> > ................
> >
> > So, it looks like request.getRequest().getCharacterEncoding() returns
> > null. Why can it be? How can I correct this error?
> >
> > Thanks!
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
--
With best regards,
Vitaly Baranovsky
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Why jetspeed sometimes doesn't return charset in content-type
of response?
Posted by Dennis Dam <d....@hippo.nl>.
Hi Vitaly,
I'm no expert on encoding, but will try to give some suggestions, the
way I see it :)
If the encoding on the HttpServletRequest is null, Jetspeed will
retrieve the preferred mediatype (which contains the character encoding)
via the capabilities map in the database. This is done by getting the
preferred mimetype for the user agent, and mapping that mimetype to a
mediatype (= the preffered mediatype). This mediatype contains the
character encoding, which is set to UTF-8 by default afaik. The
character encoding contained in this mediatype is used as a fallback, in
case the encoding is not set on the HttpServletRequest (by the container
I guess).
See this piece of code in CapabilityValveImpl:
if (encoding == null)
{
if (mediaType != null && mediaType.getCharacterSet() != null)
{
encoding = mediaType.getCharacterSet();
}
}
You can try to use remote debugging to see what's going on in
CapabilityValveImpl:
* what's the incoming character encoding on the HttpServletRequest? Is
it null, an empty string or utf-8 ?
* is the loaded preferred mediatype correct, does it have UTF-8 encoding?
If nothing else works, you can try to set the encoding on the
HttpServletRequest:
* you can set the default server encoding to UTF-8 in your container
(Tomcat):
JAVA_OPTS="-Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8"
* If that doesn't work, you can try to set the character encoding with a
servlet filter, although I have no idea if it is best practice to do so,
or even possible. Anybody else who knows?
Dennis
Vitaly Baranovsky wrote:
> Hi all!
>
> Usually jetspeed returns "text/html;charset=UTF-8" in response. But
> sometimes after restart of tomcat server it returns just "text/html"
> for every response till a next restart.
>
> I've digged into code and found in method CapabilityValve.invoke next
> lines of code:
> ................
> String encoding = request.getRequest().getCharacterEncoding();
> ................
> if (encoding != null)
> {
> contentType.append("; charset=" + encoding);
> }
> ................
>
> So, it looks like request.getRequest().getCharacterEncoding() returns
> null. Why can it be? How can I correct this error?
>
> Thanks!
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org