Hallo,
Das Problem ist in solchen Fällen (Connection reset by peer) meist der Client, genauer dessen Anbindung an das Netz. Prüfe ob das Skript gelegentlich ungewöhnlich lange zum Antworten braucht.
Der Client muss in diesem Fall gar nicht auf die Antwort warten ...
doch, muss er. Gemäß der HTTP-Spezifikation "muss" er auch bei einem HEAD-Request die Antwort entgegennehmen, die in diesem Fall nur aus den Response-Headern besteht. Tut er es nicht, ist das eine Verletzung der Regeln von HTTP. Zwar sollte das den Server nicht weiter jucken, aber der Eintrag ins Error-Log ist trotzdem berechtigt.
wo wiederum fastcgi_finish_request() vermeiden sollte, dass der Abbruch des Clients relevant ist.
Das Manual sagt dazu:
fastcgi_finish_request() - special function to finish request and flush all data while continuing to do something time-consuming (video converting, stats processing etc.);
Ich verstehe das so, dass das Script von der Kommunikation mit dem Client abgekoppelt wird, die Server-Client-Kommunikation aber trotzdem korrekt ablaufen sollte, nur dass sie eben schon abgeschlossen werden darf und kann, bevor das Script endet. Für den korrekten Ablauf muss der Client aber dennoch die Antwort abholen, die er "bestellt" hat.
Warum das in deinem Fall einige Clients nicht tun, wissen wir nicht - es könnte, wie Jörg vermutet hat, an einer unzuverlässigen Verbindung liegen. Das halte ich in der Häufung aber für unwahrscheinlich. Ich vermute eher eine unsaubere Implementierung im clientseitigen Ablauf. Der muss ja wohl auch irgendwas Spezielles sein, denn HEAD-Requests stellt ein gewöhnlicher Browser AFAIK nicht von sich aus.
So long,
Martin
Es sagte...
ein korpulenter Lehrer zu einem Schüler, der ihn ein Fass genannt hatte: "Nein. Ein Fass ist von Reifen umgeben, ich dagegen von Unreifen."
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(