fastcgipp-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fastcgipp-users] Re: form handler crashing if posts key missing


From: Eddie Carle
Subject: Re: [Fastcgipp-users] Re: form handler crashing if posts key missing
Date: Tue, 05 Jan 2010 13:31:34 -0700

On Wed, 2010-01-06 at 00:13 +1030, address@hidden wrote:
> Hmm, looks like I may have solved this one too .. 
>  
> If I change the form's enctype to 'multipart/form-data', blank form
> fields are no 
> longer fatal. 
> Does this sound right? 
>  
> Mike 
>  
> Note: I've included the original post below as lists.gnu.org seemed to
> be down 
> and I'm not sure it ever made it through: 
>  
> ///////////////////////////////////////////////////////////////// 
>  
> I am having issues with a form handling program crashing whenever an
> expected 
> environment.posts[ ] key is not present. 
>  
> I can test for the existence of the key using
> environment.postVariableExists(), 
> but all attempts to handle this so far have not worked and the program
> still crashes. 
>  
> For example: 
>  
> std::string input_name; 
> if (environment.postVariableExists("name")) { 
> input_name = environment.posts["name"].value; 
> } 
> else { 
> input_name = "empty"; 
> } 
>  
> // now do something with input_name; 
>  
>  
> Program works fine if key is present, but crashes if not. 
> I would expect that the contents of the 'if' block would only be
> examined if the 
> key existed, but it appears that maybe that isn't the case. 
>  
> Any suggestions on how to handle missing POST data gratefully
> accepted. 
>  
> I am using Nginx + FastCGI is that is relevant. 

multipart/form-data and application/x-www-form-urlencoded are the two
types of post data handled. Both are handled by separate handler
functions. See Fastcgipp::Http::Environment<charT>. It would appear as
though the handler for application/x-www-form-urlencoded does not check
for valid keys before looking them up. This is not necessarily a bug,
but it may be.
--
        Eddie Carle





reply via email to

[Prev in Thread] Current Thread [Next in Thread]