HTTP 1.1 is keep-alive by default. If "Connection" header is not set, it is assumed keep-alive. EP_FILE always sets Content-Length, thus it is OK for it to be keep-alive. EP_USER assumes that event handler uses "chunked" functions, so it's OK for EP_USER to be keep-alive too. The rest of endpoints (e.g. CGI) are not guaranteed to set Content-Length, thus they're closing the connection.
On Thu, Jun 12, 2014 at 11:35 PM, Terence Martin <walts....@gmail.com> wrote: > I'm noticing now that it always seems to act as through there was a > keep-alive header in the original request, even if there was not. I'm not > sure if that's a big deal or not, but there is a should_keep_alive() > internal function that looks like it's trying to decide if the connection > should be kept alive or not. > > Incidentally, that function seems to think that only connection with an > endpoint type of EP_USER should be allowed to be kept alive, but when it's > called in close_local_endpoint(), it checks to see if the endpoint type is > EP_USER or EP_FILE. > > > > > On Thursday, June 12, 2014 10:25:21 AM UTC-7, Sergey Lyubka wrote: > >> Yeah that's how connection param should be used, you're correct. Don't >> forget to set it back to null after dealloc. Also dealloc at mgclose to >> avoid leaks. >> On Jun 12, 2014 6:19 PM, "Terence Martin" <walt...@gmail.com> wrote: >> >>> Indeed now both types of queries are treated the same. The diff on that >>> is where I traced things to yesterday, even. >>> >>> In my simple example code, I'm using connection_param to hold the >>> structure that indicates what sort of processing I'm waiting for completion >>> on. >>> >>> So in this case, I think it's safest to dealloc and null out that >>> parameter once the MG_POLL is indicating that it's done. In the best case, >>> the connection is used for simple queries until it closes, and in the worst >>> case it might get re-used for a second long-lived query that would >>> overwrite connection_param and leak it. >>> >>> Many thanks for the fix and the clarification on intended behaviour. >>> >>> On Thursday, June 12, 2014 2:59:34 AM UTC-7, Sergey Lyubka wrote: >>>> >>>> I've made a quick test and realized that long-lived connections are >>>> closed. >>>> Pushed https://github.com/cesanta/mongoose/commit/3cec6f6745 >>>> ea9714bc77ff332072beea279bfe82 >>>> Now they're kept alive. >>>> Please verify. >>>> >>>> >>>> On Thu, Jun 12, 2014 at 10:42 AM, Sergey Lyubka <val...@gmail.com> >>>> wrote: >>>> >>>>> Hi Terence, >>>>> I expect the connection to be kept alive in both cases (short-lived >>>>> and long-lived requests). >>>>> What does your handler return on MG_POLL event? >>>>> >>>>> >>>>> On Wed, Jun 11, 2014 at 10:15 PM, Terence Martin <walt...@gmail.com> >>>>> wrote: >>>>> >>>>>> I have a question regarding keep-alive connections and the MG_CLOSE >>>>>> event, in particular in how they interact if you're using the >>>>>> connection_param field in the mg_connection structure. >>>>>> >>>>>> The documentation for MG_CLOSE says: >>>>>> >>>>>> MG_CLOSE is sent when the connection is closed. This event is used >>>>>>> to cleanup per-connection state stored in connection_param if it >>>>>>> was allocated. >>>>>> >>>>>> >>>>>> However, I have noticed that in the case of a keep-alive connection, >>>>>> MG_CLOSE doesn't trigger until the idle timeout is reached (which makes >>>>>> sense). This would mean that if this connection was a keep-alive and the >>>>>> client issued a second request, the connection_param would still be set >>>>>> as >>>>>> for the previous connection. >>>>>> >>>>>> In my case I'm having MG_REQUEST start a query and return MG_MORE, >>>>>> then using MG_POLL to check if it's complete yet and dispatch away the >>>>>> results if they are. To be safe I'm discarding the structure right in the >>>>>> MG_POLL once it's no longer needed and nulling the field out to make sure >>>>>> that if this connection was kept-alive, the next MG_POLL wouldn't use the >>>>>> structure inappropriately. >>>>>> >>>>>> In my limited testing it looked like simple requests (in which >>>>>> MG_REQUEST returns MG_TRUE) will stay alive, while connections in which >>>>>> MG_REQUEST returns MG_MORE get MG_CLOSE invoked as soon as the data is >>>>>> transmitted. However, I'm not sure if that's by design, a fluke, or my >>>>>> test >>>>>> is doing something wonky. >>>>>> >>>>>> What's the best principles approach to this? >>>>>> >>>>>> -- >>>>>> 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 mongoose-user...@googlegroups.com. >>>>>> To post to this group, send email to mongoos...@googlegroups.com. >>>>>> Visit this group at http://groups.google.com/group/mongoose-users. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>> -- >>> 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 mongoose-user...@googlegroups.com. >>> To post to this group, send email to mongoos...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/mongoose-users. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > 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 mongoose-users+unsubscr...@googlegroups.com. > To post to this group, send email to mongoose-users@googlegroups.com. > Visit this group at http://groups.google.com/group/mongoose-users. > For more options, visit https://groups.google.com/d/optout. > -- 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 mongoose-users+unsubscr...@googlegroups.com. To post to this group, send email to mongoose-users@googlegroups.com. Visit this group at http://groups.google.com/group/mongoose-users. For more options, visit https://groups.google.com/d/optout.
