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

[Michael Lenaghan]

>>  * 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?

#define MHD_HTTP_HEADER_COOKIE "Cookie"
#define MHD_HTTP_HEADER_SET_COOKIE "Set-Cookie"
#define MHD_HTTP_HEADER_SET_COOKIE2 "Set-Cookie2"

>>  * 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.

Yes, but the docs say that the log callback passes it to the access
callback, not the content callback. I think the content callback is
where it's more likely needed. Or, at least, no less needed.

But in the grand scheme of things it's only a minor inconvenience. I
just didn't know whether it was consciously intended or simply the
by-product of a different intent. It's intentional, so I don't think
it's worth discussing further. Thanks.

>>  * 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.

OK, I have to mull that over a bit. Thanks for the explanation.

>>  * 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).

I was thinking that if a client closed a connection unexpectedly it
might generate a SIGPIPE. If that's true--I'm not sure--then EINTR
might be an expected thing rather than an unexpected thing. And if
it's expected it might as well be in the example because otherwise it
would become an FAQ anyway. (Or a very subtle and very
hard-to-reproduce bug.) In any event, I thought I'd ask.

Thanks, Christian. All around. :-)