You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Kai Benndorf <ka...@pb.izm.fhg.de> on 2003/12/01 10:52:36 UTC

Re: Spaces in request parameters: Problems with raw-request-param

Hi Tony,

i've opened  the following bug:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25102

Best Regards

Kai



Tony Collen schrieb:

> Kai Benndorf wrote:
>
>> Hi all,
>>
>> in my Cocoon application i process a HTML formular and request XML 
>> data from an http request using the standard FileGenerator: Something 
>> similar to:
>>
>>     <map:generate 
>> src="http://localhost/FMPRO?-db=KD_Produkt_DB&amp;producer={raw-request-param:SEARCH-producer} 
>> label="content"/>
>>
>> I 've problems if the parameter SEARCH-producer contains white space, 
>> like 'Agon GmbH'. I was glad when i found the 
>> RawRequestParameterModule, which should exactly do what i needed 
>> here, delivering the parameters as delivered from the  web client 
>> 'Agon+GmbH'. But it doesn't work! The parameter comes still as 'Agon 
>> GmbH'.
>>
>> Many thanks in advance for any hint.
>
>
> Kai,
>
> I've recently noticed this problem, too.... unfortunately I haven't 
> had a lot of time to look into this... I may have some time to 
> investigate in the coming week or so.
>
> In the meantime, would you mind opening a bug in bugzilla with your 
> test case?
>
> Regards,
>
> Tony
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>


-- 
----------------------------------------------------------------
Dipl.-Inf. Kai Benndorf
Fraunhofer-Institut für Zuverlässigkeit und Mikrointegration IZM
Abteilung: Advanced System Engineering
Technologiepark 34                   PHONE: (++49) 5251 5402-131
33100 Paderborn                             (++49) 5261 920832
Germany                              FAX:   (++49) 5251 5402-105
                       E-MAIL: kai.benndorf@pb.izm.fraunhofer.de
                       URL: http://www.pb.izm.fraunhofer.de/kmsd
----------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: Spaces in request parameters: Problems with raw-request-param

Posted by Tony Collen <co...@umn.edu>.
Joerg Heinicke wrote:
> Hello Tony,
> 
> please read the mail at 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106796038708692&w=2. It 
> seems to be exactly the same problem. Can you confirm this?

I'm not too sure. It's a similar problem (things being decoded when they shouldn't), but I get the 
following output when I replace URLDecoder.decode(uri) with just "uri":

With the request in my browser:

http://localhost:8888/raw-test/request+plus+whitespace?parameter+plus+whitespace=val+plus+whitespace

uri:          raw-test/request+plus+whitespace
decoded:      raw-test/request plus whitespace
querystring:  parameter+plus+whitespace=val+plus+whitespace
requestUri:   /raw-test/request+plus+whitespace

The last two lines are from request.getQueryString() and request.getRequestURI(), respectively.

IMHO request.getRequestURI() should return the URI as it was sent (i.e. encoded always).  Removing 
the URLDecoder.decode() seems to fix this, but I'm not sure what else this breaks ;)

Getting back to the raw-request module:

- With the URLDecoder.decode() removed, the module still returns things decoded, so I think the 
problems are not related. Looking through some of my servlet books and Java API docs, there is no 
way to get an "encoded" request parameter value from HttpServletRequest.

> 
> Joerg

WDYT?

Tony


Re: Spaces in request parameters: Problems with raw-request-param

Posted by Joerg Heinicke <jo...@gmx.de>.
Hello Tony,

please read the mail at 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106796038708692&w=2. It 
seems to be exactly the same problem. Can you confirm this?

Joerg

On 01.12.2003 19:25, Tony Collen wrote:

> (I am bringing this thread over to -dev to ask the experts for help)
> 
> Kai Benndorf wrote:
> 
>> Hi Tony,
>>
>> i've opened  the following bug:
>>
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25102
>>
>> Best Regards
>>
>> Kai
> 
> 
> Alright, due to my limited knowledge of Avalon, and my brain being in a 
> general state of rustiness, I'm having some problems.
> 
> Here's what I know so far:
> 
> - The RawRequestParameterModule is not actually giving raw request 
> parameters (i.e. URL-Encoded)
> 
> Reading from the Javadocs:
>  * RawRequestParameterModule accesses request parameters without
>  * decoding or casting. It uses the get() method instead of the 
> getParameter()
>  * method of the {@link org.apache.cocoon.environment.Request Request} 
> This is useful
>  *  for example in conjunction with uploads.
> 
> - The RRPM uses this to get the request parameter:
> 
>     ObjectModelHelper.getRequest(objectModel).get( pname );
> 
> Alright, so I track down Cocoon's HttpRequest (and also the Request 
> interface).  Looking at both, I see no mention of a contract where 
> Request.get(parameter) must return the parameter's value encoded.
> 
> Looking further into o.a.c.e.h.HttpRequest, I notice:
> - If the request is not a MultipartHttpServletRequest, the following is 
> used:
>     String[] values = req.getParameterValues(name);
> 
> Alright, here, req is a plain old 
> javax.servlet.http.HttpServletRequest.  The Javadocs for 
> getParameterValues says the following:
> 
> "Returns an array of String objects containing all of the values the 
> given request parameter has, or null if the parameter does not exist."
> 
> It says nothing about being encoded.
> 
> AFAIK, the only way to get encoded (or "raw") request parameter values 
> is to look at the raw query string and break it up on & characters, or 
> break it up on the request parameter separator .. I know that PHP allows 
> you to set the parameter separator character to something else (most 
> commonly ';').  But now I'm getting off on a tangent.
> 
> Anybody have suggestions?
> 
> Regards,
> 
> Tony, feeling tired after typing up this long message.


Re: Spaces in request parameters: Problems with raw-request-param

Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Tony Collen wrote:
> Christian Haul wrote:
> 
>> I'm fine with any solution that tries to maintain current behaviour as 
>> much as possible. Indeed, there
>> is a necessity to access the undecoded parameters or at least easily 
>> access  re-encoded parameters.
>> Mind you, though, that you might need to encode the parameter name as 
>> well! E.g "parameter[1]=foo++bar"
>> is not useful either.
> 
> 
> Yep, I was thinking this myself, and was wondering how we would handle 
> parameters with spaces as well.
> 
>>
>> So my interest here is to keep the way open for accessing uploads. 
>> Depending on a check for instanceof String
>> might be enough. A "meta" module probably cleaner.
> 
> 
> IMO the meta module is cleaner, yes.  That way we can filter anything 
> through URL encoding/decoding as needed, and not just sitemap 
> parameters.  If modules aren't added by tomorrow I'll work on it.

Just another thought: The JXPath based modules (request-param is not but 
request is) allow to call arbitrary java methods. I don't know the 
syntax off head but there are examples on the JXPath site how to do it 
(well, they don't illustrate our modules but since the string on the 
right hand side of the colon is passed to JXPath as is, it is applicable 
here. There might even be samples in our javadocs.)

	Chris.


Re: Spaces in request parameters: Problems with raw-request-param

Posted by Tony Collen <co...@umn.edu>.
Christian Haul wrote:

> I'm fine with any solution that tries to maintain current behaviour as 
> much as possible. Indeed, there
> is a necessity to access the undecoded parameters or at least easily 
> access  re-encoded parameters.
> Mind you, though, that you might need to encode the parameter name as 
> well! E.g "parameter[1]=foo++bar"
> is not useful either.

Yep, I was thinking this myself, and was wondering how we would handle 
parameters with spaces as well.

> 
> So my interest here is to keep the way open for accessing uploads. 
> Depending on a check for instanceof String
> might be enough. A "meta" module probably cleaner.

IMO the meta module is cleaner, yes.  That way we can filter anything 
through URL encoding/decoding as needed, and not just sitemap 
parameters.  If modules aren't added by tomorrow I'll work on it.


> 
>    Chris.
> 
> 


Regards,

Tony


Re: Spaces in request parameters: Problems with raw-request-param

Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Geoff Howard wrote:

> Christian Haul wrote:
>
>> Tony Collen wrote:
>>
>>> Kai Benndorf wrote:
>>>
>>>> Hi Tony,
>>>>
>>>> if there really is no way to get the encoded request parameter, 
>>>> although it's not very smart, we still have the possibility to 
>>>> encode the parameter anew. Is there already an existing  function 
>>>> to encode the parameter somewhere?
>>>>
>>>> Regards
>>>>
>>>> Kai
>>>
>>>
>>>
>>>
>>> Well, if we can't solve the problem correctly, the quick and dirty 
>>> solution is to manually re-encode the value inside the inputmodule 
>>> using java.net.URLEncoder.encode().
>>>
>>> Still working on it.. must have patience! :)
>>
>>
>>
>> If you do this, please bear in mind that I made this module for a 
>> purpose: to get at the uploaded data.
>> The Request.getParameter() method unfortunately converts them to 
>> java.lang.String which effectively
>> prevents this. So, if you change this module, please check that the 
>> object is a String before re-encoding
>> it. And check that the upload sample in the databases block works 
>> with the modification.
>
>
> If it turns out that the un-decoded (raw) parameter really should 
> never be returned from the Request, then it makes more sense to 
> introduce a "url-encode" input module which would encode a given 
> string, including the output of another module for use as a valid url 
> in the sitemap. IIRC there have been users with valid use cases for 
> this with no way to automatically come up with the value. 


I'm fine with any solution that tries to maintain current behaviour as 
much as possible. Indeed, there
is a necessity to access the undecoded parameters or at least easily 
access  re-encoded parameters.
Mind you, though, that you might need to encode the parameter name as 
well! E.g "parameter[1]=foo++bar"
is not useful either.

So my interest here is to keep the way open for accessing uploads. 
Depending on a check for instanceof String
might be enough. A "meta" module probably cleaner.

    Chris.



Re: Spaces in request parameters: Problems with raw-request-param

Posted by Geoff Howard <co...@leverageweb.com>.
Christian Haul wrote:

> Tony Collen wrote:
> 
>> Kai Benndorf wrote:
>>
>>> Hi Tony,
>>>
>>> if there really is no way to get the encoded request parameter, 
>>> although it's not very smart, we still have the possibility to encode 
>>> the parameter anew. Is there already an existing  function to encode 
>>> the parameter somewhere?
>>>
>>> Regards
>>>
>>> Kai
>>
>>
>>
>> Well, if we can't solve the problem correctly, the quick and dirty 
>> solution is to manually re-encode the value inside the inputmodule 
>> using java.net.URLEncoder.encode().
>>
>> Still working on it.. must have patience! :)
> 
> 
> If you do this, please bear in mind that I made this module for a 
> purpose: to get at the uploaded data.
> The Request.getParameter() method unfortunately converts them to 
> java.lang.String which effectively
> prevents this. So, if you change this module, please check that the 
> object is a String before re-encoding
> it. And check that the upload sample in the databases block works with 
> the modification.

If it turns out that the un-decoded (raw) parameter really should never 
be returned from the Request, then it makes more sense to introduce a 
"url-encode" input module which would encode a given string, including 
the output of another module for use as a valid url in the sitemap. 
IIRC there have been users with valid use cases for this with no way to 
automatically come up with the value.

Just my .02,

Geoff


Re: Spaces in request parameters: Problems with raw-request-param

Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Tony Collen wrote:

> Kai Benndorf wrote:
>
>> Hi Tony,
>>
>> if there really is no way to get the encoded request parameter, 
>> although it's not very smart, we still have the possibility to encode 
>> the parameter anew. Is there already an existing  function to encode 
>> the parameter somewhere?
>>
>> Regards
>>
>> Kai
>
>
> Well, if we can't solve the problem correctly, the quick and dirty 
> solution is to manually re-encode the value inside the inputmodule 
> using java.net.URLEncoder.encode().
>
> Still working on it.. must have patience! :)

If you do this, please bear in mind that I made this module for a 
purpose: to get at the uploaded data.
The Request.getParameter() method unfortunately converts them to 
java.lang.String which effectively
prevents this. So, if you change this module, please check that the 
object is a String before re-encoding
it. And check that the upload sample in the databases block works with 
the modification.

Cheers,
    Chris.




Re: Spaces in request parameters: Problems with raw-request-param

Posted by Tony Collen <co...@umn.edu>.
Kai Benndorf wrote:

> Hi Tony,
> 
> if there really is no way to get the encoded request parameter, although 
> it's not very smart, we still have the possibility to encode the 
> parameter anew. Is there already an existing  function to encode the 
> parameter somewhere?
> 
> Regards
> 
> Kai

Well, if we can't solve the problem correctly, the quick and dirty 
solution is to manually re-encode the value inside the inputmodule using 
java.net.URLEncoder.encode().

Still working on it.. must have patience! :)

Tony


Re: Spaces in request parameters: Problems with raw-request-param

Posted by Kai Benndorf <ka...@pb.izm.fhg.de>.
Hi Tony,

if there really is no way to get the encoded request parameter, although 
it's not very smart, we still have the possibility to encode the 
parameter anew. Is there already an existing  function to encode the 
parameter somewhere?

Regards

Kai

Tony Collen schrieb:

> (I am bringing this thread over to -dev to ask the experts for help)
>
> Kai Benndorf wrote:
>
>> Hi Tony,
>>
>> i've opened  the following bug:
>>
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25102
>>
>> Best Regards
>>
>> Kai
>
>
> Alright, due to my limited knowledge of Avalon, and my brain being in 
> a general state of rustiness, I'm having some problems.
>
> Here's what I know so far:
>
> - The RawRequestParameterModule is not actually giving raw request 
> parameters (i.e. URL-Encoded)
>
> Reading from the Javadocs:
>  * RawRequestParameterModule accesses request parameters without
>  * decoding or casting. It uses the get() method instead of the 
> getParameter()
>  * method of the {@link org.apache.cocoon.environment.Request Request} 
> This is useful
>  *  for example in conjunction with uploads.
>
> - The RRPM uses this to get the request parameter:
>
>     ObjectModelHelper.getRequest(objectModel).get( pname );
>
> Alright, so I track down Cocoon's HttpRequest (and also the Request 
> interface).  Looking at both, I see no mention of a contract where 
> Request.get(parameter) must return the parameter's value encoded.
>
> Looking further into o.a.c.e.h.HttpRequest, I notice:
> - If the request is not a MultipartHttpServletRequest, the following 
> is used:
>     String[] values = req.getParameterValues(name);
>
> Alright, here, req is a plain old 
> javax.servlet.http.HttpServletRequest.  The Javadocs for 
> getParameterValues says the following:
>
> "Returns an array of String objects containing all of the values the 
> given request parameter has, or null if the parameter does not exist."
>
> It says nothing about being encoded.
>
> AFAIK, the only way to get encoded (or "raw") request parameter values 
> is to look at the raw query string and break it up on & characters, or 
> break it up on the request parameter separator .. I know that PHP 
> allows you to set the parameter separator character to something else 
> (most commonly ';').  But now I'm getting off on a tangent.
>
> Anybody have suggestions?
>
> Regards,
>
> Tony, feeling tired after typing up this long message.
>     
>
>
>
>



Re: Spaces in request parameters: Problems with raw-request-param

Posted by Kai Benndorf <ka...@pb.izm.fhg.de>.
Hi Tony,

if there really is no way to get the encoded request parameter, although 
it's not very smart, we still have the possibility to encode the 
parameter anew. Is there already an existing  function to encode the 
parameter somewhere?

Regards

Kai

Tony Collen schrieb:

> (I am bringing this thread over to -dev to ask the experts for help)
>
> Kai Benndorf wrote:
>
>> Hi Tony,
>>
>> i've opened  the following bug:
>>
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25102
>>
>> Best Regards
>>
>> Kai
>
>
> Alright, due to my limited knowledge of Avalon, and my brain being in 
> a general state of rustiness, I'm having some problems.
>
> Here's what I know so far:
>
> - The RawRequestParameterModule is not actually giving raw request 
> parameters (i.e. URL-Encoded)
>
> Reading from the Javadocs:
>  * RawRequestParameterModule accesses request parameters without
>  * decoding or casting. It uses the get() method instead of the 
> getParameter()
>  * method of the {@link org.apache.cocoon.environment.Request Request} 
> This is useful
>  *  for example in conjunction with uploads.
>
> - The RRPM uses this to get the request parameter:
>
>     ObjectModelHelper.getRequest(objectModel).get( pname );
>
> Alright, so I track down Cocoon's HttpRequest (and also the Request 
> interface).  Looking at both, I see no mention of a contract where 
> Request.get(parameter) must return the parameter's value encoded.
>
> Looking further into o.a.c.e.h.HttpRequest, I notice:
> - If the request is not a MultipartHttpServletRequest, the following 
> is used:
>     String[] values = req.getParameterValues(name);
>
> Alright, here, req is a plain old 
> javax.servlet.http.HttpServletRequest.  The Javadocs for 
> getParameterValues says the following:
>
> "Returns an array of String objects containing all of the values the 
> given request parameter has, or null if the parameter does not exist."
>
> It says nothing about being encoded.
>
> AFAIK, the only way to get encoded (or "raw") request parameter values 
> is to look at the raw query string and break it up on & characters, or 
> break it up on the request parameter separator .. I know that PHP 
> allows you to set the parameter separator character to something else 
> (most commonly ';').  But now I'm getting off on a tangent.
>
> Anybody have suggestions?
>
> Regards,
>
> Tony, feeling tired after typing up this long message.
>     
>
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: Spaces in request parameters: Problems with raw-request-param

Posted by Tony Collen <co...@umn.edu>.
(I am bringing this thread over to -dev to ask the experts for help)

Kai Benndorf wrote:
> Hi Tony,
> 
> i've opened  the following bug:
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25102
> 
> Best Regards
> 
> Kai

Alright, due to my limited knowledge of Avalon, and my brain being in a general state of rustiness, 
I'm having some problems.

Here's what I know so far:

- The RawRequestParameterModule is not actually giving raw request parameters (i.e. URL-Encoded)

Reading from the Javadocs:
  * RawRequestParameterModule accesses request parameters without
  * decoding or casting. It uses the get() method instead of the getParameter()
  * method of the {@link org.apache.cocoon.environment.Request Request} This is useful
  *  for example in conjunction with uploads.

- The RRPM uses this to get the request parameter:

     ObjectModelHelper.getRequest(objectModel).get( pname );

Alright, so I track down Cocoon's HttpRequest (and also the Request interface).  Looking at both, I 
see no mention of a contract where Request.get(parameter) must return the parameter's value encoded.

Looking further into o.a.c.e.h.HttpRequest, I notice:
- If the request is not a MultipartHttpServletRequest, the following is used:
     String[] values = req.getParameterValues(name);

Alright, here, req is a plain old javax.servlet.http.HttpServletRequest.  The Javadocs for 
getParameterValues says the following:

"Returns an array of String objects containing all of the values the given request parameter has, or 
null if the parameter does not exist."

It says nothing about being encoded.

AFAIK, the only way to get encoded (or "raw") request parameter values is to look at the raw query 
string and break it up on & characters, or break it up on the request parameter separator .. I know 
that PHP allows you to set the parameter separator character to something else (most commonly ';'). 
  But now I'm getting off on a tangent.

Anybody have suggestions?

Regards,

Tony, feeling tired after typing up this long message.
	




Re: Spaces in request parameters: Problems with raw-request-param

Posted by Tony Collen <co...@umn.edu>.
(I am bringing this thread over to -dev to ask the experts for help)

Kai Benndorf wrote:
> Hi Tony,
> 
> i've opened  the following bug:
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25102
> 
> Best Regards
> 
> Kai

Alright, due to my limited knowledge of Avalon, and my brain being in a general state of rustiness, 
I'm having some problems.

Here's what I know so far:

- The RawRequestParameterModule is not actually giving raw request parameters (i.e. URL-Encoded)

Reading from the Javadocs:
  * RawRequestParameterModule accesses request parameters without
  * decoding or casting. It uses the get() method instead of the getParameter()
  * method of the {@link org.apache.cocoon.environment.Request Request} This is useful
  *  for example in conjunction with uploads.

- The RRPM uses this to get the request parameter:

     ObjectModelHelper.getRequest(objectModel).get( pname );

Alright, so I track down Cocoon's HttpRequest (and also the Request interface).  Looking at both, I 
see no mention of a contract where Request.get(parameter) must return the parameter's value encoded.

Looking further into o.a.c.e.h.HttpRequest, I notice:
- If the request is not a MultipartHttpServletRequest, the following is used:
     String[] values = req.getParameterValues(name);

Alright, here, req is a plain old javax.servlet.http.HttpServletRequest.  The Javadocs for 
getParameterValues says the following:

"Returns an array of String objects containing all of the values the given request parameter has, or 
null if the parameter does not exist."

It says nothing about being encoded.

AFAIK, the only way to get encoded (or "raw") request parameter values is to look at the raw query 
string and break it up on & characters, or break it up on the request parameter separator .. I know 
that PHP allows you to set the parameter separator character to something else (most commonly ';'). 
  But now I'm getting off on a tangent.

Anybody have suggestions?

Regards,

Tony, feeling tired after typing up this long message.
	




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org