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 <address@hidden
<mailto:address@hidden>> 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