Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aryeh.friedman@gmail.com
 designates 72.14.220.154 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=lDw1h0biGku+bs1V2xGLUiV1IGOWofa0en4ZFhW8cBjyIufTPietO5ki0V5OkyQisU
         gZ4V+mBnU5CygZZZwZJeGYgYNCPRCy5TSH+pSNdahI6rjdIHvrfPwkMIJGvgmNcM72kg
         KOrl6CsHjuWStq2POb012vMmgt6oQ8KnIEMzc=
Message-ID: <4B8D7D59.7030208@gmail.com>
Date: Tue, 02 Mar 2010 16:04:25 -0500
From: "Aryeh M. Friedman" <aryeh.friedman@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20100120)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: unified doXXX()
References: <4B89CE2A.3000104@gmail.com> <4B8A8B17.2050200@pidster.com>
 <4B8B744C.9080608@gmail.com> <4B8BA461.10906@apache.org>
 <4B8CB569.3070507@gmail.com> <4B8D5384.3060400@christopherschultz.net>
 <4B8D6511.3070104@gmail.com> <4B8D78A6.7010001@christopherschultz.net>
 <4B8D79A4.6080604@gmail.com> <4B8D7BE0.5060601@christopherschultz.net>
In-Reply-To: <4B8D7BE0.5060601@christopherschultz.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Aryeh,
>
> On 3/2/2010 3:48 PM, Aryeh M. Friedman wrote:
>   
>> Christopher Schultz wrote:
>>
>>     
>>> Is this a new client, or just a new data format? Mark's suggestion that
>>> you may be using POST without the proper Content-Type would result in
>>> getting null for this parameter (because Tomcat will not parse it for
>>> you). If this is the case, you should either fix the new client to use
>>> the proper Content-Type, or fall-back to reading and parsing the request
>>> body manually when these requirements are not met.
>>>   
>>>       
>> New format same frontend client code which does use the proper content
>> type. (the content type is defined at a lower level then the format and
>> that code has not changed [using firebug on firefox confirms that fact])
>>     
>
> Hmm.
>
> So, POST + application/x-www-form-urlencoded yields a null parameter
> with your new payload?
>
> I know this sounds silly, but we're getting down to the
> grasping-at-straws level, here, so bear with me: have you checked to see
> that your request body is actually in the correct format (that is,
> urlencoded, etc.)? I haven't looked at the Tomcat code, but Tomcat might
> give up if the request body is not parsable.
>
> Have you tried calling request.getInputStream and dumping the request
> body when the parameter is null? That might give you some indication of
> what's happening.
>   
The client does url encode in addition to translating any chars that are 
used either by tomcat and/or or app to decode the reaquest (namely = is 
translated to ^, comma to #, right/left parens to @ and $ respectivally) 
then I use javascripts "escape(string)" method to url encode it.... the 
app by default uses post but if I cut and paste the resulting payload 
into a GET and pass it to the app it works fine (i.e. the app uses POST 
but I do manual testing with GET)

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