Thanks Ken. See my follow-up email. (May have crossed-paths with yours?) I learned more about how MHD is doing things and found where I think the problem is.
MHD is doing the URL decoding as part of its built-in post-processor x-www-form-urlencoded data. The problem is that it's not decoding the +'s to spaces. I can't do it after the fact because MHD will have already converted '%2B' to +'s - i.e., I can't just swap out all the +'s for spaces in the post-processor iterator callback because some of them might actually be +'s. In other words - MHD is doing the decoding, just not all of it (the MHD decoding code doesn't take +'s into account). It seems to me that the only solution is for MHD to properly decode the +'s, or for me to not use the built-in post-processor. Or am I missing something? Is there a pre-post-processor callback I don't know about where I could do the +-to-space swap myself? Seems kinda wasteful, but that would work too. Thanks again, Ken On Wed, Sep 17, 2014 at 9:19 AM, Ken Teh <[email protected]> wrote: > The 'urlencoded' in application/x-www-form-urlencoded' says it all. When > the ajax call posts the request it converts spaces to '+'s as it should. > You just need to url decode it. > > > On 09/17/2014 07:44 AM, Kenneth Mastro wrote: > >> All, >> >> I'm using MHD's post-processor to process form data and several AJAX >> requests. I have noticed that when the encoding is >> 'application/x-www-form-urlencoded', >> strings with spaces contain a '+' sign instead of the spaces. >> >> For form data, if I explicitly set the encoding to 'multipart/form-data', >> the strings are parsed properly and there are no '+'s, which is how I've >> been getting around the problem (I assumed I was doing something wrong and >> haven't had time to dig into it). However, this isn't working for my AJAX >> requests - setting the encoding to 'multipart/form-data' breaks things in >> ways I haven't fully investigated, yet. I consider that a hack anyway, so >> I don't really want to pursue it. I need to figure out why >> 'application/x-www-form-urlencoded' isn't working for me. >> >> In looking at the 'Content-Type' the server is receiving for the AJAX >> requests, it is 'application/x-www-form-urlencoded; charset=UTF-8'. I >> thought the charset might be causing an issue, but I'm having trouble >> getting jQuery to not use UTF-8. From the jQuery ajax page: "The W3C >> XMLHttpRequest specification dictates that the charset is always UTF-8; >> specifying another charset will not force the browser to change the >> encoding." I.e., I'm stuck with UTF-8 because it's the standard, which I'm >> fine with. Regardless, MHD successfully creates the post processor, so >> it's seeing the actual base encoding (this works because it only compares >> the first chunk of chars of the content type - essentially ignoring the >> charset part). >> >> MHD does not seem to provide an option for REPLACING a header (i.e., >> using MHD_set_connection_value only ADDS a header - it won't replace the >> existing Content-Type header), so even if I actually could be sure the data >> was ASCII, I can't fix this in the server without doing my own POST >> processing. I doubt that would work anyway unless I could get the web page >> / browser to not do UTF-8 somehow. (Although I think ASCII is a subset of >> UTF-8, maybe there are differences even in those low-numbered characters >> I'm not aware of?) >> >> Anyway - In short - my question is: Is the MHD post processor just >> failing on 'application/x-www-form-urlencoded' data? I.e., it's not >> parsing out the +'s when it should? Or, does MHD not work with UTF-8 >> encoded data (despite the all the characters being in the ASCII range) and >> I need to do my own POST processing? Or, does this actually work and I'm >> just doing something wrong? >> >> >> Thanks much, >> Ken >> >> >
