[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] POST processing "any" mime type
From: |
Andreas Wehrmann |
Subject: |
Re: [libmicrohttpd] POST processing "any" mime type |
Date: |
Thu, 24 Nov 2011 14:55:50 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111105 Thunderbird/8.0 |
On 11/24/2011 11:46 AM, Christian Grothoff wrote:
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
Thanks for your reply.
I do know that the PostProcessor provides data incrementally
which is why I collect the data in a map when working with forms until
there is no more upload data.
I just thought I could reuse these callbacks for different kinds of data,
because the behaviour is the same (data gradually arriving), that's why
I even thought of it.
In short: I had the faint idea of being able to register a callback function
for a user specified MIME type to the library.
In retrospect thinking of the minimalistic approach of this library,
this would probably be bad as it would introduce useless indirections
(as pointed out by you :-) )
As for now, I did already implement a generic processor which
in case of an unsupported MIME type just collects the data and passes it on.
Regards,
Andreas
--
Dipl.-Ing. (FH) Andreas Wehrmann
Software Development
--------------------------------------------------------------
Center Communication Systems GmbH
A-1210 Wien, Ignaz-Köck-Straße 19
Sitz in Wien
FN 796 88p, Firmenbuchgericht Wien
www.centersystems.com
Tel.: +43 (0) 190 199 - 3616
Mobile: +43 (0) 664 884 75916
Fax: +43 (0) 190 199 - 2110
E-Mail: address@hidden