Hi Cyril, On Wed, Oct 22, 2014 at 09:28:39AM +0200, Cyril Bonté wrote: > Hi Willy, > > Le 22/10/2014 09:08, Willy Tarreau a écrit : > >Could you please check in your log if you find other requests from the > >same IP:port ? I'm wondering if we can't have something like this in the > >case of keep-alive when a prior request was sent to stats for example (in > >which case we'd have to fix it of course). > > Yes it can, yesterday I talked about redirects because without the > configuration I thought it was the most common case, but it can also > happen when a browser requests the stats page then the service, and > reuses the connection. > > >Could you please check if all requests giving this are all POST ? > >The request state could come from the fact that the full body was > >not completely received (eventhough in this config extract I'm not > >seeing anything waiting for some body). And that will not explain the > >local flag either. > > For example, I could also see that when the browser requested a > /favicon.ico after accessing to the stats page, a LR flag was set on > /favicon.ico.
OK thanks for checking! > >Thus I have no idea for now. If you could find other such logs, it could > >possibly help getting a clue. > > I wonder if the flags shouldn't be cleaned up more than it is in > http_end_txn_clean_session(), but I'm not sure and didn't have time to > check this yesterday. > Something like : > s->flags &= ~(SN_ERR_MASK | SN_FINST_MASK); Absolutely, it ought to be done, I'm even surprized we don't have it! It's possible that it accidently disappeared some time ago. It's also possible that it has never been there because previously, we did not support keep-alive on stats, so all non-empty termination codes caused the connection to be closed, and we never noticed it. If you have some time to prepare a patch doing this and to test it, I'll happily merge it. Otherwise I can do it, so it's as you like. Thanks, Willy
