You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by wesley <we...@263.net> on 2008/12/17 00:41:00 UTC

Dispatcher encoding and locale bug still not fixed

Hi there,

The method prepare() in org.apache.struts2.dispatcher.Dispatcher will 
forcefully set the encoding and locale of a HttpRequest if there were 
defaultEncoding and defaultLocale in global settings, causing the original 
encoding and locale (if there were any) of the Request being unexpected 
overwritten.

 Please take just 5 minutes to examine the code:

=======================================
    /**
     * Prepare a request, including setting the encoding and locale.
     *
     * @param request The request
     * @param response The response
     */
    public void prepare(HttpServletRequest request, HttpServletResponse 
response) {
        String encoding = null;
        if (defaultEncoding != null) {
            encoding = defaultEncoding;
        }

        Locale locale = null;
        if (defaultLocale != null) {
            locale = LocalizedTextUtil.localeFromString(defaultLocale, 
request.getLocale());
        }

        if (encoding != null) {
            try {
                request.setCharacterEncoding(encoding);
            } catch (Exception e) {
                LOG.error("Error setting character encoding to '" + encoding 
+ "' - ignoring.", e);
            }
        }

        if (locale != null) {
            response.setLocale(locale);
        }

        if (paramsWorkaroundEnabled) {
            request.getParameter("foo"); // simply read any parameter 
(existing or not) to "prime" the request
        }
    }
=======================================

Normally I'm put this line in struts.xml to define the default encoding:
<constant name="struts.i18n.encoding" value="UTF-8"/>
If I did so, every request will be unconditionally treated as encoded with 
UTF-8, no matter what was set to be encoded with explicitly.
I supply a patch as follow:
=======================================
 /**
  * Prepare a request, including setting the encoding and locale.
  *
  * @param request  The request
  * @param response The response
  */
 public void prepare(HttpServletRequest request, HttpServletResponse 
response) {
  String encoding = request.getCharacterEncoding();
  if (encoding == null && defaultEncoding != null) {
   try {
    request.setCharacterEncoding(defaultEncoding);
   } catch (Exception e) {
    LOG.error("Error setting character encoding to '" + defaultEncoding + 
"' - ignoring.", e);
   }
  }

  Locale locale = request.getLocale();
  if (locale == null && defaultLocale != null) {
   locale = LocalizedTextUtil.localeFromString(defaultLocale, 
request.getLocale());
   if (locale != null) {
    response.setLocale(locale);
   }
  }

  if (paramsWorkaroundEnabled) {
   request.getParameter("foo"); // simply read any parameter (existing or 
not) to "prime" the request
  }
 }
=======================================

You guys may not think this to be a bug, because most of u rarely use 
Chinese/Japanese character
set or browsers localized in these language . Different client browsers will 
encode the URL with
different encoding before they send requests to server!!

Would someone take just 5 minutes to see whether the logic in 
Dispatcher::prepare() is correct or not.

BTW, Glad to see the 2.1 will soon go to GA and see some great heros save 
Convention plugin from dustbin.

regards
-Wesley


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Dispatcher encoding and locale bug still not fixed

Posted by Nils-Helge Garli Hegvik <ni...@gmail.com>.
I assume this is the same as
https://issues.apache.org/struts/browse/WW-2361? I'm not sure what the
original semantics behind the "defaultEncoding" or the
"struts.i18n.encoding" setting is, but I agree that it looks
suspicious...

Could you create a patch and attach it to the issue?

Nils-H

On Wed, Dec 17, 2008 at 12:41 AM, wesley <we...@263.net> wrote:
> Hi there,
>
> The method prepare() in org.apache.struts2.dispatcher.Dispatcher will
> forcefully set the encoding and locale of a HttpRequest if there were
> defaultEncoding and defaultLocale in global settings, causing the original
> encoding and locale (if there were any) of the Request being unexpected
> overwritten.
>
> Please take just 5 minutes to examine the code:
>
> =======================================
>   /**
>    * Prepare a request, including setting the encoding and locale.
>    *
>    * @param request The request
>    * @param response The response
>    */
>   public void prepare(HttpServletRequest request, HttpServletResponse
> response) {
>       String encoding = null;
>       if (defaultEncoding != null) {
>           encoding = defaultEncoding;
>       }
>
>       Locale locale = null;
>       if (defaultLocale != null) {
>           locale = LocalizedTextUtil.localeFromString(defaultLocale,
> request.getLocale());
>       }
>
>       if (encoding != null) {
>           try {
>               request.setCharacterEncoding(encoding);
>           } catch (Exception e) {
>               LOG.error("Error setting character encoding to '" + encoding +
> "' - ignoring.", e);
>           }
>       }
>
>       if (locale != null) {
>           response.setLocale(locale);
>       }
>
>       if (paramsWorkaroundEnabled) {
>           request.getParameter("foo"); // simply read any parameter
> (existing or not) to "prime" the request
>       }
>   }
> =======================================
>
> Normally I'm put this line in struts.xml to define the default encoding:
> <constant name="struts.i18n.encoding" value="UTF-8"/>
> If I did so, every request will be unconditionally treated as encoded with
> UTF-8, no matter what was set to be encoded with explicitly.
> I supply a patch as follow:
> =======================================
> /**
>  * Prepare a request, including setting the encoding and locale.
>  *
>  * @param request  The request
>  * @param response The response
>  */
> public void prepare(HttpServletRequest request, HttpServletResponse
> response) {
>  String encoding = request.getCharacterEncoding();
>  if (encoding == null && defaultEncoding != null) {
>  try {
>   request.setCharacterEncoding(defaultEncoding);
>  } catch (Exception e) {
>   LOG.error("Error setting character encoding to '" + defaultEncoding + "' -
> ignoring.", e);
>  }
>  }
>
>  Locale locale = request.getLocale();
>  if (locale == null && defaultLocale != null) {
>  locale = LocalizedTextUtil.localeFromString(defaultLocale,
> request.getLocale());
>  if (locale != null) {
>   response.setLocale(locale);
>  }
>  }
>
>  if (paramsWorkaroundEnabled) {
>  request.getParameter("foo"); // simply read any parameter (existing or not)
> to "prime" the request
>  }
> }
> =======================================
>
> You guys may not think this to be a bug, because most of u rarely use
> Chinese/Japanese character
> set or browsers localized in these language . Different client browsers will
> encode the URL with
> different encoding before they send requests to server!!
>
> Would someone take just 5 minutes to see whether the logic in
> Dispatcher::prepare() is correct or not.
>
> BTW, Glad to see the 2.1 will soon go to GA and see some great heros save
> Convention plugin from dustbin.
>
> regards
> -Wesley
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org