libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] POST processing "any" mime type


From: Christian Grothoff
Subject: Re: [libmicrohttpd] POST processing "any" mime type
Date: Thu, 24 Nov 2011 11:46:49 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15

On 11/24/2011 11:16 AM, Andreas Wehrmann wrote:
I noticed that MHD_create_post_processor() refuses to create a processor
when the
MIME type is not "application/x-www-form-urlencoded" or
"multipart/form-data".

Right, that is the documented and intended behavior.

However, I'd like to post process data of a different type (i.e.
"application/json").
I could do this manually in the access handler of course,
but I would like to reuse the mechanism that libmicrohttpd already
implements.

I'm not sure how that would work or what the benefit would be. To begin with, the MHD_PostDataIterator is supposed to supply a *key* argument (note that that argument is not allowed to be NULL), which would not be known for an unknown mime type.

In the case for MIME types for which the library doesn't implement any
handling,
it could just call the user function directly, providing the content type.

What do you think?

I think this would be an incompatible API change (existing applications may rely on this function 'failing' for odd encoding types) and it should be trivial for you to implement whatever behavior you desire if you get the 'failing' (NULL) return value from 'MHD_create_post_processor' (simply query the mime type yourself and call your handler, that's 2 lines of code).

Not to mention, typically I would expect that your code knows which encoding to expect (at least Json vs. form-data) and thus you'd know which way to process the data to begin with. And if you know that you have a data format that requires a specific parser (like Json), why would you want to involve the MHD_PostProcessor in the first place -- as it can do nothing useful for you (note that the PostProcessor does NOT buffer the data to give you the "entire" upload). As far as I see it, passing the data via the PostProcessor would just add a few useless indirections in cases where the PostProcessor parser is not suitable.

Happy hacking,

Christian



reply via email to

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