I believe the RawRequestParameterModule input module may be the answer here. This will provide access to the original (URLEncoded) parameter. Otherwise it's like the RequestParameterModule.
Cheers Con > -----Original Message----- > From: Joerg Heinicke [mailto:[EMAIL PROTECTED] > Sent: Friday, 24 October 2003 10:55 > To: [EMAIL PROTECTED] > Subject: Re: URL encoding for request > > > On 23.10.2003 13:35, Fleischer Roman wrote: > > > I think it is a problem for the used "searcheDatabase > Servlet". For the > > result I use a file-generator, but in reality it is a service like: > > <map:generate > > > src="http://server1.inside.com?cmd=configurator.SearchProduct&; > amp;output=xml > > > &keyword={request-param:searchString}&cmid={request-pa > ram:cmid}"/> > > This was already mentioned short time ago: In the sitemap the request > params are available as strings, not in any encoded form. So, you are > right, the parameters are no longer URL encoded for the > servlet request. > Tony, didn't you have a similar problem? How have you fix it (if)? > > > When I use UTF-8 encoding for form-encoding and ISO-8859-1 for > > container-encoding "Gießharz" is sending to the servlet. If > both are UTF-8 > > something like "Gie~A#harz" is sent to the servlet. > > Container encoding should always be ISO-8859-1, independent > on the form > handling. This is important for reading text files like properties or > similar. > > > I ask the developer of the servlet, what kind of format he > needs. He needs > > the format "Gie%C3%9Fharz" and a special information in the > http-request > > header that the encoding is UTF-8. > > > > Can i send a param with the request header to a generator, > or should i use a > > HTTP-generator instead? > > I don't know exactly what's all possible with the proxy generators. > Maybe Tony can jump in? But maybe having the parameters URL encoded > already works. > > Joerg > > > -----Original Message----- > > From: Joerg Heinicke [mailto:[EMAIL PROTECTED] > > Sent: Donnerstag, 23. Oktober 2003 09:41 > > To: [EMAIL PROTECTED] > > Subject: Re: URL encoding for request > > > > > > Seems to be more weird than it should be. In your database there is > > "Gießharz" I think and not the URL encoded form of it. > Furthermore the > > string is correctly in your pipelines, so everything should > work. But > > some representations of this string are not correct, so > that they don't > > match. One of them is the search result HTML ("Your search for > > "GieEUR?harz" has no hits."). I guess you have to debug > around a bit > > where the string is "Gießharz" and where not. It should > always be in > > this representation internally. What about encoding (ISO-8859-1 vs. > > UTF-8)? How does your searchPageResult pipeline look like? > > > > Joerg > > > > On 23.10.2003 09:11, Fleischer Roman wrote: > > > > > >>Hello Joerg, > >> > >>thank you for the quick answer. I will tell my case, resp. show my > > > > problem. > > > >>I use a search form with the input field searchString. The > form action is > >>OCIprod (a matcher in the cocoon sitemap). > >>When i look to the log-files the request is URL encoded > >> > > > > > (http://127.0.0.1/cocoon/OCIprod?searchString=Gie%C3%9Fharz&se archMLFB=&sear > > > >>c....) > >> > >>The OCI prod matcher looks like this: > >><map:match pattern="OCIprod"> > >><map:generate type="request"/> > >><map:transform type="xslt" src="product.xsl"/> > >><map:transform type="cinclude"/> > >><map:transform type="encodeURL"/> > >><map:serialize type="html"/> > >></map:match> > >> > >>In the stylesheet product.xsl i use a cinclude to show the > search result > >><xsl:param name="searchString" > >> > > > > > select="request:requestParameters/request:[EMAIL PROTECTED]'sea > rchString']/re > > > >>quest:value/text()"/> > >>... > >><xsl:if test="$search='result'"> > >><cinclude:include > >> > > > > > src="cocoon:/searchPageResult?lang={$lang}&searchString={$ searchString}" > > > >>/> > >></xsl:if> > >> > >>Now the param $searchString has the value "Gießharz" instead of > >>"Gie%C3%9Fharz" and can not be found in the database. I get > an error on > > > > the > > > >>searchPage result page like "Your search for "GieEUR?harz" > has no hits. If > > > > I > > > >>call the searchPageResult direct in the browser with URL encoded > >>searchString everything works. > >> > >>What is my error? > >>Thanks > >> > >> > >>-----Original Message----- > >>From: Joerg Heinicke [mailto:[EMAIL PROTECTED] > >>Sent: Donnerstag, 23. Oktober 2003 01:19 > >>To: [EMAIL PROTECTED] > >>Subject: Re: URL encoding for request > >> > >> > >>Hello Roman, > >> > >>for the request generator the decoding is okay. It gives > the request > >>params in their string representation in an XML structure. It knows > >>nothing about an URL encoded string. (%C3%9F is URl > encoded, not UTF > >>encoded!!) > >> > >>Maybe it's better to tell us your use case. If you > transform the output > >>of the request generator back into a HTML page with links, > the @href > >>will be URL encoded again - at least that should be done by the XML > >>serializer. > >> > >>Joerg > >> > >>On 21.10.2003 14:10, Fleischer Roman wrote: > >> > >> > >> > >>>Hello, > >>> > >>>i have some problems with URL encoding. > >>>I call a matcher in this form: > >>> > >> > >> > > > http://127.0.0.1/cocoon/OCIprod?searchString=Gie%C3%9Fharz&sea rchMLFB=&searc > >>>h=result... >>>(%C3%9F is the german "ss") >>> >>>In the matcher i call a request generator and a xml-serializer. >>>The result is: >>>... >>><h:requestParameters> >>> <h:parameter name="searchString"> >>> <h:value>Gießharz</h:value> >>> </h:parameter> >>> <h:parameter name="search"> >>> <h:value>result</h:value> >>>... >>> >>>Why is the parameter searchString transformed? How can i aviod the >>>transforming? I need this param UTF-8 encoded (like in the calling URL) >>> >>>Any idea? >>>Thanks... > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
