Re: [libmicrohttpd] Comments and Questions on Features from a Newbie

[Christian Grothoff]

On Monday 05 October 2009 03:30:45 Michael Lenaghan wrote:
> Hello.
> 
> I just plugged libmicrohttpd into an app this weekend. Thank you! The
> process was pretty smooth, and it seems to be working quite well. I'm
> still poking around, but I have a few questions and comments.
> 
>  * It would be helpful (I think) if defaults for the various options
> were documented--eg, MHD_OPTION_CONNECTION_LIMIT,
> MHD_OPTION_CONNECTION_TIMEOUT, etc. (I can read the code to find the
> defaults; I'm just suggesting it would be useful to state what the
> defaults are. Of course, I might have simply missed them...)

I agree. Will do.
 
>  * Why are no header defines for cookies? I understand the alternate
> interfaces available, but still--shouldn't there be MHD_HTTP_HEADER_
> macros defined...? Or is that, um, very strong encouragement to avoid
> the headers?

I don't understand what you'd like to have here.  We certainly don't intend to 
discourage any particular use.  Could you give me some example for the kind of 
#define you'd find useful?

>  * Why is there no query string in the content callback? I understand
> the alternate interface there too, and I understand that there's a
> "URL log" callback, but wouldn't it make sense to simply pass the
> query string as a parameter? (I'm plugging into a scripting language
> and that seems to be the way of things for many scripting languages.)

That's because we don't copy it.  We read the request from the network into a 
(request-specific) buffer and then convert it (in-place) into the 0-terminated 
strings that you can access using the "normal" header-access interface.  In 
order to *keep* the query string, we'd have to copy it, which would double 
memory requirements and be (hopefully, typically) useless work.  

Since some applications do need a copy, we provided the URL log callback which 
gives them the opportunity to do the copying before we parse (and thereby 
destroy) the URI string if needed.
 
>  * Why is the content callback called twice with pos = 0? Is that a
> bug or is that a sanity check by the library? (I also noticed that
> buffers were fixed at 2k but it looks like that was recently reported
> and fixed.)

The very first callback is for HTTP 100 continue (giving you an opportunity to 
do something else, like return a 404); after we've sent the HTTP 100 continue 
the client can then push data to us.  While this is only technically needed 
for 1.1, we do it *always* since we want to hide the fact that there maybe 
different protocol versions from the user of MHD as much as possible.

>  * Should the file server example check for EINTR on an error return from
>  fread?

Depends a bit on what your fileserver maybe doing.  MHD itself should not cause 
any interrupts during the fread.  Now, if you embedded this into a larger 
application, then maybe you should check.  Regardless, the code is an example 
and as such I'd not say it needs to be feature-complete, especially with 
regards to things that it is not trying to show (and the file-IO part is not 
what the example is about, the example is about the MHD API, so only that part 
should be as complete as possible).

Best,

Christian

-- 
http://grothoff.org/christian/