[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?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
0x939E6BE1E29FC3CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature