libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] Issue getting escaped binary data in MHD_KeyValueIte


From: Christian Grothoff
Subject: Re: [libmicrohttpd] Issue getting escaped binary data in MHD_KeyValueIterator
Date: Wed, 20 Mar 2019 10:49:05 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

Thanks for reporting!

I've implemented this as suggested in e2c268e3..1b610e5b (tested things
still work, but no _extensive_ testing).  Note that this will cause a
(harmless) compiler warning for code using the previous API.  Adding an
explicit cast to MHD_KeyValueIterator will suppress the warning while
preserving forward and backward compatibility.

Code that depends on the new behavior MUST test for MHD version being >=
0.9.64.

Happy hacking!

Christian

On 3/19/19 10:27 PM, Joe Cossette wrote:
> Have been using libmicrohttpd for some time and it performs great.
> Currently using version 0.9.59.
> 
>  
> 
> I’ve encountered a situation I’m not sure how to solve using the library
> and hoping someone may be able to help.
> 
>  
> 
> The issue is likely a corner case, but valid nonetheless.
> 
>  
> 
> It involves getting escaped binary data using the function
> MHD_get_connection_values with the MHD_GET_ARGUMENT_KIND option.
> 
>  
> 
> A simplified example of a submitted URI looks like this:
> 
>  
> 
>            
> http://n.n.n.n/sendsms?to=123456789&udh=%06%05%04%0f%ea%00%03&text=Hello
> 
>  
> 
> As you can see, there is a binary zero before the end of the escaped key
> udh, but RFC1738 appears to mention that binary zero’s are valid in
> escaped strings.
> 
>  
> 
> The problem arises in the MHD_KeyValueIterator callback routine.  The
> library correctly delivers the decoded binary string value, but there
> doesn’t seem to be a way to get the correct length of this argument
> because a normal strlen() function returns a truncated length value due
> to the presence of a NULL character value.
> 
>  
> 
> It seems to me that since binary data is a valid payload in the URI that
> instead of a const char* for the value of the MHD_KeyValueIterator
> callback, that perhaps the callback prototype should look something more
> like the following:
> 
>  
> 
> typedef int (*MHD_KeyValueIterator) (void *cls,
> 
>                          enum MHD_ValueKind kind,
> 
>                          const char *key,
> 
>                          const unsigned char *value,
> 
>   int value_length);
> 
>  
> 
> If it did even this corner case could get covered properly.
> 
>  
> 
> The only other solution I can think of is to parse the complete URI
> myself, which negates some of the library’s functionality.
> 
>  
> 
> Any other suggestion?
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 

Attachment: 0x939E6BE1E29FC3CC.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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