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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev >

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/j... > > 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]

> (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

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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>> >> >> >

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/j... >>> >>> 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.

>> >>> (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(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>> >>>> >>>> >>> >> >> >

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 ?

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/j... >>>>> >>>>> 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(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > >

are we talking here about Portlet parameters or something else ?

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/j... >>>>>>> >>>>>>> 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(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > >

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/j... > > > > > > > > > > > > > > > > > > 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(a)lists.jboss.org > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/gatein-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >