nginx/php-fpm: HEAD und Connection reset by peer

[Tanja]

Guten Abend,

bei HEAD-Requests tauchen beim nginx/php-fpm gelegentlich (nicht immer!) Meldungen in der error.log des Webservers auf. Sämtliche POST/GET Aufrufe sind erfolgreich, jedoch gelingen HEAD Aufrufe nicht immer.
Leider ist es nicht möglich, alle REQUESTs umzustellen.

Da diese REQUESTs den Webserver (erfolgreich) erreichen und in den _GET-Parametern alle Information enthalten sind, die zur Weiterverarbeitung (in diesem Fall Logging) erforderlich sind, vorliegen, soll es nicht weiter stören, dass clientseitig die Verbindung unterbrochen wird.
Im Skript rufe ich zudem fastcgi_finish_request() auf, um genau das zu erreichen.

Dennoch erhalte ich immer noch derartige Meldungen:
2013/06/09 19:20:58 [error] 10405#0: *820861265 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 77.185.20.111, server: web-serv.er, request: "HEAD /short-call.php"

Gibt es einen Tipp, um diese Aufrufe ordnungsgemäß verarbeiten zu können?
Schönen Abend

[Jörg Reinholz]

bei HEAD-Requests tauchen beim nginx/php-fpm gelegentlich (nicht immer!) Meldungen in der error.log des Webservers auf.

...

Dennoch erhalte ich immer noch derartige Meldungen:
2013/06/09 19:20:58 [error] 10405#0: *820861265 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 77.185.20.111, server: web-serv.er, request: "HEAD /short-call.php"

Wie oft denn?

Gibt es einen Tipp, um diese Aufrufe ordnungsgemäß verarbeiten zu können?

Telefonica, Hostname ist "brln-4db9146f.pool.mediaWays.net"

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.

Jörg Reinholz

[Tanja]

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 und veranlasst lediglich den Anruf. Alles weitere passiert serverseitig, wo wiederum fastcgi_finish_request() vermeiden sollte, dass der Abbruch des Clients relevant ist.

Es passiert in <10% der Requests mit HEAD (und das PHP-Script erreicht nie ein Laufzeit Limit).

Auf die Providerwahl der Nutzer habe ich leider ebenso wenig Einfluss wie auf deren Browserwahl etc. Dennoch würde ich sogar REQUESTs von mobilen Geräte mit noch instabilerer Datenverbindung erfolgreich erfassen wollen, ohne erst noch die error.log parsen zu müssen.

[Der Martin]

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

[Jörg Reinholz]

denn HEAD-Requests stellt ein gewöhnlicher Browser AFAIK nicht von sich aus.

Jein. Wenn er durch vorherige Header zu bestimmten Maßnahmen des Cachings aufgefordert wird macht er das. Eine diese Maßnahmen ist das Verwenden eines E-TAG.

Aber Du hast vollkommen Recht mit dem "Nicht von sich aus".

Was jetzt das Ausgangsproblem betrifft:

Lässt sich denn nachvollziehen, ob die betroffenen Requests abgearbeitet wurden? Wenn die Beschreibung stimmt und die Requests abgearbeitet wurden, dann kann man diese "unvermeidbaren" Einträge im error-log ignorieren. Freilich kann auch das Logging tunen, notfalls(!) sogar beim loggen selbst durch den grep "jagen".

Jörg Reinholz

[Der Martin]

Hi,

denn HEAD-Requests stellt ein gewöhnlicher Browser AFAIK nicht von sich aus.
Jein. Wenn er durch vorherige Header zu bestimmten Maßnahmen des Cachings aufgefordert wird macht er das. Eine diese Maßnahmen ist das Verwenden eines E-TAG.

ich kann natürlich keine für sämtliche Browser und alle Situationen gültige Aussage treffen, aber nach meinen eigenen Beobachtungen setzen die gängigen Browser (ich hab seinerzeit Opera, IE und Firefox beobachtet) auch dann einen GET-Request ab. Und zwar mit einem If-Modified-Since-Header, und erwarten dann entweder Status 200 und frische Daten, oder 304 und keine Daten.

Lässt sich denn nachvollziehen, ob die betroffenen Requests abgearbeitet wurden? Wenn die Beschreibung stimmt und die Requests abgearbeitet wurden, ...

Da sollte man zunächst wissen, was "abgearbeitet" hier bedeutet. Eigentlich ist ja der Sinn eines HEAD-Requests die Feststellung, ob eine bestimmte Ressource existiert bzw. erreichbar ist. Ein HEAD ohne die Antwort abzuwarten ist, als würde man jemanden anrufen und wieder auflegen, noch bevor der Angerufene ans Telefon geht. Und einen HEAD-Request als Auslöser für eine tatsächliche Aktion zu verwenden, ist eigentlich nicht im Sinn des Erfinders; dafür sollte man besser GET oder POST verwenden.
Deshalb ist bisher mein Eindruck, dass Tanjas Anwendungsfall irgendwie nicht ganz sauber durchdacht ist.

Ciao,
 Martin

[Jörg Reinholz]

ich kann natürlich keine für sämtliche Browser und alle Situationen gültige Aussage treffen, aber nach meinen eigenen Beobachtungen setzen die gängigen Browser (ich hab seinerzeit Opera, IE und Firefox beobachtet) auch dann einen GET-Request ab.

Ja. Ich weiss aber auch nicht mehr ganz genau, was ich getan habe. Ich habe beim "restlos durchoptimieren" des Cachings von fastix.org auch mal head-requests mit dem Firefox erzeugt. Bitte frag jetzt nicht genaueres, ich habe 60 km Radfahren hinter mir.

Lässt sich denn nachvollziehen, ob die betroffenen Requests abgearbeitet wurden? Wenn die Beschreibung stimmt und die Requests abgearbeitet wurden, ...

Da sollte man zunächst wissen, was "abgearbeitet" hier bedeutet.

Nun ja. Ich vermute aus Tanjas Äußerungen, sie loggt irgendwas.

Und einen HEAD-Request als Auslöser für eine tatsächliche Aktion zu verwenden, ist eigentlich nicht im Sinn des Erfinders; dafür sollte man besser GET oder POST verwenden.

Dem stimme ich voll zu. Was übrigens die Ursache für den Abbruch betrifft: Möglicherweise ein (transparenter) Proxy? Irgendwelche Firewalls? Spamblocker? Das Problem liegt (laut Tanja) nicht am Server.

Deshalb ist bisher mein Eindruck, dass Tanjas Anwendungsfall irgendwie nicht ganz sauber durchdacht ist.

Tja so ist es. Wir wissen leider nichts genaueres.

Jörg Reinholz