[gatein-dev] Setting URIEncoding to UTF-8 in server.xml

Thu Mar 18 11:53:02 EDT 2010

I'm assuming that UIPortlet do the same and use the query string  
parser when it constructs the parameter passed to the portlet invoker.

Is that what you mean ?

On Mar 18, 2010, at 3:19 PM, Matthew Wringe wrote:

> On Thu, 2010-03-18 at 15:04 +0100, Julien Viet wrote:
>> are we talking here about Portlet parameters or something else ?
>
> We are talking about request parameters. But if we are getting the  
> wrong
> values from the request parameters, and passing on those values to the
> pc, then we get back wrongly encoded portlet parameters.
>
>> On Mar 18, 2010, at 2:20 PM, Matthew Wringe wrote:
>>
>>> On Wed, 2010-03-17 at 23:39 +0100, Julien Viet wrote:
>>>> portlet request context are I believe different as they are never
>>>> encoded to anything except they are passed in clear as a kind of
>>>> Map<String,String[]>, so where would be the encoding problem ?
>>>
>>> there isn't (unless you are passing the wrongly encoded strings).
>>> I have a patch ready, I just need to wait until its safe to start
>>> committing again.
>>>
>>>> On Mar 17, 2010, at 11:08 PM, Matthew Wringe wrote:
>>>>
>>>>> On Wed, 2010-03-17 at 21:38 +0100, Julien Viet wrote:
>>>>>> On Mar 17, 2010, at 8:54 PM, Julien Viet wrote:
>>>>>>
>>>>>>>
>>>>>>> On Mar 17, 2010, at 8:48 PM, Matthew Wringe wrote:
>>>>>>>
>>>>>>>> On Wed, 2010-03-17 at 20:20 +0100, Julien Viet wrote:
>>>>>>>>> Hi Matt
>>>>>>>>>
>>>>>>>>> in WCI there is code to decode query parameters using UTF-8
>>>>>>>>> charset:
>>>>>>>>>
>>>>>>>>> http://anonsvn.jboss.org/repos/gatein/components/wci/trunk/wci/src/main/java/org/gatein/wci/util/RequestDecoder.java
>>>>>>>>>
>>>>>>>>> that delegates most of the job to :
>>>>>>>>> org.gatein.common.http.QueryStringParser
>>>>>>>>
>>>>>>>> hmm, ok, so it handles the querystring parameters directly from
>>>>>>>> the
>>>>>>>> url
>>>>>>>> and not from the request properties. Which means we need to
>>>>>>>> bypass
>>>>>>>> the
>>>>>>>> request parameters itself to add this feature. We can do this  
>>>>>>>> in
>>>>>>>> the
>>>>>>>> PortalRequestContext [or maybe we should wait to add this  
>>>>>>>> feature
>>>>>>>> until
>>>>>>>> a later date? with wci]
>>>>>>>
>>>>>>> I think you can handle the request query string at any time,  
>>>>>>> what
>>>>>>> needs to be changed is how the portal consumer the query string
>>>>>>> as a
>>>>>>> parameter map.
>>>>>>>
>>>>>>
>>>>>> i.e, the request parameter in webui should parse the query string
>>>>>> in
>>>>>> UTF8 and make them probably available via the class  
>>>>>> RequestContext:
>>>>>>
>>>>>>  abstract public String getRequestParameter(String name);
>>>>>>
>>>>>>  abstract public String[] getRequestParameterValues(String name);
>>>>>>
>>>>>> and any call to obtain a request parameter should use this.
>>>>>
>>>>> that will work for the PortalRequestContext, but not the
>>>>> PortletRequestContext (since that uses the portlet responses  
>>>>> instead
>>>>> of
>>>>> the http ones).
>>>>>
>>>>> I have a patch for it that will make the PortalRequestContext work
>>>>> this
>>>>> way, and then makes the UIPortlet use the parameter map from the
>>>>> PortalRequestContext which is used by the pc to set the
>>>>> PortletRequestContext.
>>>>>
>>>>>
>>>>>>>>
>>>>>>>>> (somehow the code of WCI: WebRequest and WebResponse should be
>>>>>>>>> used in
>>>>>>>>> GateIn in a later feature release, as it provides value add
>>>>>>>>> services
>>>>>>>>> on top of HTTP request/response)
>>>>>>>>
>>>>>>>> yeah, it probably should, that code isn't being used right now
>>>>>>>>
>>>>>>>
>>>>>>> Thomas and myself will probably discuss about that in a near
>>>>>>> future.
>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mar 17, 2010, at 7:36 PM, Matthew Wringe wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, 2010-03-17 at 18:59 +0100, Julien Viet wrote:
>>>>>>>>>>> actually it is servlet container specific so we want to  
>>>>>>>>>>> avoid
>>>>>>>>>>> it.
>>>>>>>>>>
>>>>>>>>>> ok, so that means we want to handle it in the portal code
>>>>>>>>>> completely
>>>>>>>>>> then?
>>>>>>>>>>
>>>>>>>>>>> where does the encoding issue occur ?
>>>>>>>>>>
>>>>>>>>>> It occurs when the url is encoded to one value, but we are
>>>>>>>>>> expecting
>>>>>>>>>> another. So when the servlet container handles decoding
>>>>>>>>>> something
>>>>>>>>>> from
>>>>>>>>>> the url (pathInfo, properties from query strings, etc...) it
>>>>>>>>>> will
>>>>>>>>>> decode
>>>>>>>>>> it using whatever encoding it has been configured to use
>>>>>>>>>> (iso-8859-1
>>>>>>>>>> by
>>>>>>>>>> default, or another value configured in the server.xml).
>>>>>>>>>>
>>>>>>>>>> So we have the situation where something we set something  
>>>>>>>>>> like
>>>>>>>>>> 'thúy' in
>>>>>>>>>> the url, the servlet container will take those bytes and
>>>>>>>>>> convert
>>>>>>>>>> them
>>>>>>>>>> into the iso-8859-1 standard (where the ú gets converted into
>>>>>>>>>> two
>>>>>>>>>> bytes), and then the string value we get back is 'thÃºy' (it
>>>>>>>>>> converts
>>>>>>>>>> the two bytes back into utf-8 characters).
>>>>>>>>>>
>>>>>>>>>> If we set the url encoding to be UTF-8 in the server.xml,
>>>>>>>>>> then we
>>>>>>>>>> don't
>>>>>>>>>> get these encoding issues since everything is handled in the
>>>>>>>>>> same
>>>>>>>>>> encoding.
>>>>>>>>>>
>>>>>>>>>> For the portal naming issue, I found a way to get around that
>>>>>>>>>> by
>>>>>>>>>> using
>>>>>>>>>> values not decoded by the servlet container. For the  
>>>>>>>>>> dashboard
>>>>>>>>>> naming
>>>>>>>>>> issue, it might be a bit more complex to handle.
>>>>>>>>>>
>>>>>>>>>> I really wish the javax.servlet classes/spec was written  
>>>>>>>>>> better
>>>>>>>>>> to
>>>>>>>>>> handle encoding issue more nicely. Some methods allow you to
>>>>>>>>>> get
>>>>>>>>>> the
>>>>>>>>>> non-decoded values, other don't. Character encoding only
>>>>>>>>>> works on
>>>>>>>>>> non-querystring properties, etc...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Mar 17, 2010, at 4:46 PM, Matthew Wringe wrote:
>>>>>>>>>>>
>>>>>>>>>>>> There have been a few issues which have been brought up in
>>>>>>>>>>>> regards
>>>>>>>>>>>> to
>>>>>>>>>>>> portal and tab names not working properly if they contain  
>>>>>>>>>>>> non
>>>>>>>>>>>> ascii
>>>>>>>>>>>> characters.
>>>>>>>>>>>>
>>>>>>>>>>>> https://jira.jboss.org/jira/browse/GTNPORTAL-337
>>>>>>>>>>>> https://jira.jboss.org/jira/browse/GTNPORTAL-596
>>>>>>>>>>>>
>>>>>>>>>>>> These are due to the portal using utf-8, while tomcat/jboss
>>>>>>>>>>>> is
>>>>>>>>>>>> configured to use iso-8859-1 encoding for the url.
>>>>>>>>>>>>
>>>>>>>>>>>> In both cases if the URIEncoding is set to UTF-8 in the
>>>>>>>>>>>> server.xml
>>>>>>>>>>>> (or
>>>>>>>>>>>> if useBodyEncodingForURI is set to true) then it works.
>>>>>>>>>>>>
>>>>>>>>>>>> For the portal naming issue it was possible to get around
>>>>>>>>>>>> it in
>>>>>>>>>>>> the
>>>>>>>>>>>> code, for the tab issue its going to be a bit more complex.
>>>>>>>>>>>>
>>>>>>>>>>>> Can we just change the URIEncoding in the server.xml for  
>>>>>>>>>>>> the
>>>>>>>>>>>> bundles
>>>>>>>>>>>> we
>>>>>>>>>>>> create? or would it be better to find workarounds for this
>>>>>>>>>>>> issue in
>>>>>>>>>>>> the
>>>>>>>>>>>> portal code itself?
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> gatein-dev mailing list
>>>>>>>>>>>> gatein-dev at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20100318/f81e9bc4/attachment-0003.html 