[Top][All Lists]

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

Re: [libmicrohttpd] Post Processing With Spaces

From: Ken Teh
Subject: Re: [libmicrohttpd] Post Processing With Spaces
Date: Wed, 17 Sep 2014 12:43:33 -0500
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.8.0

Hi Ken,

Yes to the crossed-paths.  Saw your subsequent post after I posted my reply.

Have you used something like firebug to see what the client is actually 
posting?  That should help you decide how to proceed.

I'm afraid I dont use the post-processor so I cannot make any suggestions.  I 
collect the entire payload and parse it myself.  I use MHD for transporting 
bytes and try to avoid the parts that deal with data-handling.

I have a Tornado-like framework in C++ based on MHD that I wrote for my 
projects.  The framework requires a fully formed request before dispatching a 
handler that is mapped to a URL regex.  Hence, collecting the entire payload.

Good luck and happy hunting.


On 09/17/2014 09:01 AM, Kenneth Mastro wrote:
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,

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:


        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 

        Thanks much,

reply via email to

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