Re: [libmicrohttpd] Processing post data

[Christian Grothoff]

On 01/11/2013 05:01 PM, Sascha Swiercy wrote:
> Sorry to bother you again. I have some more questions/issues:
> 
> - I was a little confused that the callback type MHD_PostDataIterator
> has a "kind" parameter, since I was expecting it to always be
> MHD_POSTDATA_KIND. Then I investigated the source code and it seems to
> me that this is indeed the only value passed to post iterators. So is
> this really true so that we can ignore the "kind" parameter within the
> callback function? In this case I would suggest to mention it in the
> documentation. (You probably don't want to remove this parameter for
> compatibility reasons, so I think a short note in the documentation
> would be the best solution.)

Yes, the parameter was there to have the function resemble callbacks
like the "MHD_KeyValueIterator".  In fact, I believe it started out as
that one, but then over time we noticed that for POST data we sometimes
needed to return more complex data structures.  So for this iterator, we
added additional arguments (and renamed the callback type) to preserve
backwards-compatibility.  I've added a note in the documentation to say
that MHD always calls it with kind=MHD_POSTDATA_KIND.

> - For MHD_POSTDATA_KIND the documentation states that post data might
> be available either as normal upload data or as part of headers which
> can be accessed through MHD_get_connection_values. I couldn't find an
> example yet where the post data was not presented as upload data, even
> with the small example given below. So is the documentation still true
> regarding this statement? It would be convenient for the user if one
> could rely on the fact that post data is always passed as upload data
> so a post processor can always be used.

Weird webpages with weird JavaScript can do all kinds of tricks.
However, you are right that for most normal applications, you don't need
MHD_get_connection_values to get POST data.  Those that need it are
usually doing something funky, and they then know why they need it.

> - I'd like to check the return value of MHD_destroy_post_processor
> which works fine if I use "multipart/form-data" as encoding. But if I
> send a request using "application/x-www-form-urlencoded", the function
> MHD_destroy_post_processor always returns MHD_NO, at least when I use
> firefox and the following HTML form to send the request:
>
> ------------------------
> <form action="http://localhost:8080/"; method="post">
> <input name="key1" type="text">
> <input name="key2" type="text">
> <input value="send" type="submit">
> </form>
> ------------------------
> 
> The post processing works just fine but MHD_destroy_post_processor
> indicates that something went wrong, which doesn't. From the source
> code it looks like there are new line characters expected at the end
> of post data, but there is no new line at the end of the request sent
> by firefox. As far as I see from the HTTP specification the request
> body is actually not required to end with a new line character. Did I
> miss something?

No, I don't think *you* missed something -- *I* simply missed that the
'\r\n' was "optional", and everyone else using the code likely never
bothered to check that return value.  I've fixed the issue in SVN 25764,
diff attached (should work for other recent releases), let me know if
that doesn't work for some reason.


Happy hacking!

Christian

optionallf.diff
Description: Text Data