Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3FCCA3EB.40902@informatik.tu-darmstadt.de>
Date: Tue, 02 Dec 2003 15:38:35 +0100
From: Christian Haul <haul@informatik.tu-darmstadt.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031013 Thunderbird/0.3
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Spaces in request parameters: Problems with raw-request-param
References: <3FC75881.5030909@pb.izm.fhg.de> <3FC7B121.5080400@umn.edu>
 <3FCB0F64.7010507@pb.izm.fhg.de> <3FCB8793.2000005@umn.edu>
 <3FCC4098.1020209@pb.izm.fhg.de> <3FCC4479.20403@umn.edu>
 <3FCC5030.4050809@informatik.tu-darmstadt.de>
 <3FCC7827.5000803@leverageweb.com>
In-Reply-To: <3FCC7827.5000803@leverageweb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.