Re: [libmicrohttpd] Bug in libmicrohttpd 0.9.39

[Christian Grothoff]

Dear Abhay,

This is expected behavior, and test_postprocessor.c shows that it
doesn't quite happen the way you describe it:  The additional call to
"post_process" happens with b='' (empty string), not '\n'.

Without this, there are cases where we might fail to report the
presence of "b" in case of URI strings like "a=1&b" or "a=1&b=".

What is likely really the problem is that your "post_process" function
incorrectly handles 'off' and 'size'.  Note that MHD does not guarantee
to give you the entier 'data' for a 'key' at once.  For example, given

a=1234567890

the PP may call you with

data=1234, size=4, off=0 and
data=567, size=3, off=4 and
data=890, size=3, off=7

and if it likes additionally
data=BOGUS, size=0, off=10

This is intended to enable incremental processing, in case we don't have
10 characters but 100 MB, or in case the network gives us the data
stream in odd fragments.

Again, the testcase exists and shows that for exactly the example you
provided I get 'size=0', and that is the expected behavior.  So in this
case, I would suggest you modify your application logic to handle
incrementally returned values.

(This is not to spite you, but because if I leave out this call, I do
get cases that start to fail, and this call with size=0 should be
'harmless' for a correct program, and might be important in those other
cases, i.e. to see 'b' in a=1&b).

Happy hacking!

Christian


On 01/09/2015 06:01 PM, Abhay Gupta wrote:
> Hi,
> 
> Pls see this code snippet
> 
> MHD_destroy_post_processor (struct MHD_PostProcessor *pp)
> {
>   int ret;
> 
>   if (NULL == pp)
>     return MHD_YES;
>   if (PP_ProcessValue == pp->state)
>   {
>     /* key without terminated value left at the end of the
>        buffer; fake receiving a termination character to
>        ensure it is also processed */
>         post_process_urlencoded (pp, "\n", 1);
>      
>      
>   }
> 
> This calling of post_process_urlencoded (pp, "\n", 1) is entirely
> incorrect and should be removed . Suppose you have a form with two
> fields a and b . On form posting the value will come as a=1&b=2 suppose
> . Since 2 is not terminated with \n it will remain in PP_ProcessValue
> and due to the above we get another post_process with b=\n.
> 
> So first we get a=1&b=2 and then we again get b=\n . This breaks the
> value of last element and obviously not required .
> 
> Regards,
> 
> Abhay

0x48426C7E.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature