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
