Hi! I am trying to wrap my head around an issue we are seeing where there are many HTTP 504 responses sent out to clients.
I suspect that due to a client bug they stop sending data midway during the data phase of the request, but they keep the connection open. What I see in the haproxy logs is a 504 response with termination flags "sHNN". That I read as haproxy getting impatient (timeout server) waiting for response headers from the backend. The backend, not having seen the complete request yet, can't really answer at this point, of course. I am wondering though, why it is that I see the I don't see a termination state indicating a client problem. So my question (for now ;-)) boils down to these points: 1) When does the server timeout actually start counting? Am I right to assume it is from the last moment the server sent or (in this case) received some data? 2) If both "timeout server" and "timeout client" are set to the same value, and the input stalls (after the headers) longer than that, is it just that the implementation is such that the server side timeout "wins" when it comes to setting the termination flags? 3) If I set the client timeout shorter than the server timeout and produced this situation, should I then see a cD state? If so, would I be right to assume that if the server were now to stall, the log could again be misleading in telling me that the client timeout expired first? I understand it is difficult to tell "who's to blame" for an inactivity timeout without knowledge about the content or final size of the request -- I just need some clarity on how the read the logs :) Thanks! Daniel -- Daniel Schneller Principal Cloud Engineer CenterDevice GmbH Rheinwerkallee 3 53227 Bonn www.centerdevice.com __________________________________________ Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina, Michael Rosbach, Handelsregister-Nr.: HRB 18655, HR-Gericht: Bonn, USt-IdNr.: DE-815299431 Diese E-Mail einschließlich evtl. beigefügter Dateien enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und löschen Sie diese E-Mail und evtl. beigefügter Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder Öffnen evtl. beigefügter Dateien sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
signature.asc
Description: Message signed with OpenPGP
