It was unexpected to me, but only because the documentation lists what events happen in what order and it doesn't mention that this happens. My initial tests while I was getting up to speed included a printf for every event in the event handler, or I wouldn't have even noticed straight away.
When I got into actually using the connection_param info is when I noticed that in cases like this the url is NULL, so I assumed that this meant that the connection object was valid but currently didn't have any connection specific data yet. I could go either way on the issue; if it stays the way it is, a quick addendum to the documentation is all that would be needed. I suppose there could be some situation in which you could use this as the opportunity to kick off some task that you know will be needed to help you fulfill the request? In my case I know that the majority of requests that arrive are going to need an IPC connection to some data services, so I could conceivably be using this as the trigger to start that if it's not already open, so that on the next pass when the request is made the connection is already built up. On Saturday, 13 September 2014 01:52:31 UTC-7, Sergey Lyubka wrote: > > On Sat, Sep 13, 2014 at 9:36 AM, Terence Martin <[email protected] > <javascript:>> wrote: > >> It's been my experience that MG_POLL is always the first event that >> triggers for a new connection. I've always assumed that this is because the >> new connection is accepted and stored before the poll starts to walk the >> connection list, though I've never looked too deeply into it. >> >> In this case, when MG_POLL triggers for the first time, the connections >> URL is NULL, though this is probably also the case for any connection that >> gets polled while mongoose is still reading the request in, so it's best to >> check the conection_param to see if it's still null or not. >> > > Usually HTTP request is transferred in one frame, meaning that once > Mongoose gets some data from an accepted socket, it can parse the request > and call MG_AUTH and MG_REQUEST handlers straight away. > > There could be cases when request is read in chunks, e.g. between the time > connection is accepted and request is fully parsed, several > mg_server_poll() calls happen. On each poll, Mongoose sends MG_POLL event. > But if request is not yet parsed, respective fields in mg_connection will > remain unset. > > Not sure is that an expected behavior or not. IMO it could be confusing to > get MG_POLL with unset URI, etc. > > Any thoughts on that? Would it be a preference to avoid MG_POLL events for > connections that are not yet buffered HTTP request? > -- You received this message because you are subscribed to the Google Groups "mongoose-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mongoose-users. For more options, visit https://groups.google.com/d/optout.
