To further clarify what Christian is saying... You have to process/parse the POST data yourself. As you noted - the built-in one only works for form data (x-www-form-urlencoded or multipart/form-data).
In other words - when the access handler gets called the first time and you see that it's a POST request, you can create a post-processor to handle it (similar to the MHD one). I.e., instead of creating one with the MHD-provided 'create post processor' function (sorry - don't have the code in front of me), you would create one of your own design. Alternatively and perhaps easier, you could not write a separate 'post processor' and just process the POST data as it comes in on the subsequent 'access handler callback' calls. (I assume that will work, anyway.) However you parse/gather the POST data... In your case, I'm guessing you'd just keep it simple and have it collect all the data from your JSON request into a string (remember - post data can appear in chunks, not necessarily all in one shot). After all POST data has come in (indicated by an upload data size of 0 ...?), you can do whatever you want with the data/string. If there is some kind of encoding applied to the string, you'll have to parse it into regular text, of course. If you want to do something really clean/slick, you could have your 'post processor code' parse the JSON into some kind of mapping that you can just ask for key/value pairs. That way, the code handling the request doesn't even need to know that it's JSON. Completely optional from your web server's perspective - it could be perfectly happy to just hand the string off to somebody else. You can hide the complexity wherever you want, but it's going to be there somewhere. :) Side note: I don't know what you're using to parse your JSON... If memory is an issue, some libraries have 'sax-like' JSON parsing (yajl comes to mind). Maybe you don't have to collect all the data before parsing some of it? Depends on what the library supports. I probably wouldn't bother with that unless memory/performance is an issue, though. Fair warning - I've never done any of this (I've only used the built-in post processor), so it may not be quite as simple as I'm describing. I can't be too far off, though. Ken On Thu, Oct 16, 2014 at 8:08 AM, Christian Grothoff <[email protected]> wrote: > Ah, yes, the MHD PostProcessor does not support 'all' possible > encoding types. If your client sends an unsupported encoding, > you need to parse "*upload_data" yourself. Note that the > MHD_PostProcessor only exists for convenience, you could write that > entire logic as a client. So please simply look at what the PP does for > the supported encodings, and then write a 'custom' PP for JSON. > > Happy hacking! > > Christian > > On 10/16/2014 02:02 PM, Matej Svejda wrote: > > Hi Christian, thank you for your reply. It seems to me that the problem > > is that post_iterator works only for data submitted by HTML forms and > > not for custom POST data. For example, if I send a request with > > Content-Type application/json to the post_example.c I get: > > > > Failed to setup post processor for `/2' > > Internal application error, closing connection. > > > > If i set the Content-Type to x-www-form-urlencoded it works but still > > tries to parse it as key-value pairs, which in my case it shouldn't. I > > am looking for a way to directly access the data submitted by post, > > regardles of the Content-Type. > > > > Regards, > > Matej >
