libmicrohttpd
[Top][All Lists]
Advanced

[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 08:19:32 -0500
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.8.0

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




reply via email to

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