libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] Question on libmicrohttpd tutorial


From: Christian Grothoff
Subject: Re: [libmicrohttpd] Question on libmicrohttpd tutorial
Date: Sun, 1 Feb 2009 19:00:56 -0700
User-agent: KMail/1.10.3 (Linux/2.6.27-9-generic; KDE/4.1.3; i686; ; )

On Sunday 01 February 2009 02:33:33 pm you wrote:
> Christian,
>
> I'm still working slowly at this but I have a question on part of the
> tutorial. You state:
>
> "Secondly, the above practice of queuing a response upon the first call
> of the callback function brings with it some limitations. This is
> because the content of the message body will not be received if a
> response is queued in the first iteration. Furthermore, the connection
> will be closed right after the response has been transferred then."
>
> Can you clarify the reasoning behind this a bit more because I think
> that I'm missing the point as to why this is necessary. Also what causes
> the callback function to be called twice in "minimal_example.c"?

I agree that this paragraph in the tutorial is very confusing.  What is going 
on is this.  The callback is called a first time right after the connection is 
accepted and the first lines of the header have been parsed.  The precise time 
when this call will happen is when we need to generate a "100 CONTINUE" 
response in an HTTP 1.1 connection.  At this point, most applications want to 
just do nothing (except maybe allocate some internal state), but certainly not 
queue a response.  However, the application should queue a response if it does 
NOT want "100 CONTINUE" to be transmitted (in which case the response from the 
application will be sent back and the connection will be closed). Most 
applications will do nothing and will receive further callbacks once all 
headers have been parsed (possibly many of those in case of a file upload).

The deal with "100 CONTINUE" can be important for applications receiving 
"POST" or "PUT" requests.  Not sending "100 CONTINUE" (but instead giving an 
error code) is a way to prevent the browser from actually doing the upload 
(which, if the request/URL is invalid, would be a good thing).  Naturally, the 
default is that the request is fine and in MHD the application doesn't need to 
explicitly transmit a "100 CONTINUE" ever.

So a good rule of thumb is this: if the request is valid, do nothing on the 
first call.  If the request is invalid, queue a response with an error code. 

I hope this helps!

Christian


reply via email to

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