Expectation failed - Apache Status 417

Q: Wie behebe ich den 417-Fehler am schnellsten?

Entferne den Expect-Header. Im Apache-Reverse-Proxy mit RequestHeader unset Expect early, in PHP cURL mit curl_setopt und einem leeren Expect-Eintrag. Danach läuft die Anfrage normal durch.

Der HTTP-Statuscode 417 Expectation Failed gehört zu den selteneren Fehlermeldungen und taucht fast immer in einer ganz bestimmten Konstellation auf: Ein Client (Browser, PHP-Skript oder ein anderer Server) schickt den Header Expect: 100-continue, und irgendeine Station auf dem Weg zum Ziel kann oder will damit nichts anfangen. Der Server antwortet dann mit dieser Meldung:

Expectation Failed
The expectation given in the Expect request-header field could not be met by this server. The client sent
Expect: 100-continue
Only the 100-continue expectation is supported.

Fehlermeldung Expectation failed mit Expect: 100-continue im Browser — So sieht die 417-Meldung aus, wenn der Expect-Header nicht durchkommt.

Bei mir trat der Fehler nach dem Update eines Reverse-Proxy-Servers auf: Seiten, die über den Proxy SOAP-Requests an einen dahinterliegenden Application-Server schickten, lieferten plötzlich nur noch die 417-Meldung. Die Ursache und die Lösung sind aber immer dieselben, egal ob es sich um SOAP, einen Datei-Upload oder ein PHP-cURL-Skript handelt. Diese Anleitung zeigt dir die Fixes für die drei häufigsten Fälle.

Was bedeutet der HTTP-Status 417 Expectation Failed?

Der Statuscode 417 signalisiert: Der Client hat im Expect-Header eine Erwartung an den Server formuliert, die dieser nicht erfüllen kann. In der Praxis gibt es dabei nur einen relevanten Wert, nämlich 100-continue. Ein Client sendet diesen Header, um vor dem Hochladen eines großen Request-Bodys erst einmal nachzufragen, ob der Server die Anfrage überhaupt annimmt. Antwortet der Server mit 100 Continue, schickt der Client die eigentlichen Daten hinterher.

Das Problem: Nicht jeder Server und vor allem nicht jeder Proxy in der Kette beherrscht diesen Zwischenschritt sauber. Antwortet eine Station stattdessen mit 417, bricht die Kommunikation ab, bevor die eigentlichen Nutzdaten übertragen werden. Der Anwender sieht dann nur die Fehlermeldung, obwohl mit seiner Anfrage inhaltlich alles in Ordnung war.

Die Ursache: der Expect: 100-continue-Header

In den allermeisten Fällen ist ein Reverse Proxy der Auslöser. Der Client spricht mit dem Proxy, der Proxy leitet die Anfrage an den eigentlichen Application-Server weiter. Wenn der Client den Expect-Header setzt, der Proxy ihn aber unverändert durchreicht und der Zielserver damit nicht umgehen kann, entsteht der 417-Fehler. Typische Auslöser sind Apache als Reverse Proxy, ein Squid davor oder eine PHP-Anwendung, die per cURL mit einem fremden Server spricht.

Die Lösung ist in allen Fällen dieselbe: Den Expect-Header entfernen, bevor die Anfrage die problematische Station erreicht. Dann verhält sich die Übertragung wieder ganz normal, der Client schickt seinen Request-Body direkt mit, ohne vorher nachzufragen.

Lösung 1: Apache Reverse Proxy - Expect-Header entfernen

Läuft der Fehler über einen Apache-Reverse-Proxy, entfernst du den Expect-Header direkt in der Konfiguration des betroffenen virtuellen Hosts. Dafür brauchst du das Modul mod_headers, das bei den meisten Apache-Installationen ohnehin aktiv ist. Trag folgendes in die VirtualHost-Konfiguration ein:

<IfModule mod_headers.c>
    RequestHeader unset Expect early
</IfModule>

Das early am Ende ist wichtig: Es sorgt dafür, dass der Header schon in einer frühen Phase der Verarbeitung entfernt wird, bevor der Proxy die Anfrage weiterreicht. Nach dem Speichern lädst du den Apache neu (apachectl graceful oder systemctl reload apache2), damit die Änderung greift. Bei mir war genau dieser Eintrag die Lösung.

Kein Zugriff auf die VirtualHost-Konfiguration? Die RequestHeader-Direktive funktioniert auch in einer .htaccess-Datei, sofern der Hoster mod_headers und die Direktive dort erlaubt (AllowOverride). Bei geteiltem Webhosting ist das aber oft gesperrt - dann bleibt nur der Weg über den Support oder die Lösung direkt im Client.

Lösung 2: PHP cURL - leeren Expect-Header senden

Wenn dein PHP-Skript per cURL Formulare oder Dateien an einen anderen Server schickt (typischerweise als multipart/form-data), setzt cURL bei größeren Datenmengen automatisch den Expect: 100-continue-Header. Bekommst du dabei einen 417-Fehler zurück, überschreibst du den Header einfach mit einem leeren Wert:

curl_setopt($curl, CURLOPT_HTTPHEADER, array('Expect:'));

Der leere Expect:-Eintrag weist cURL an, den Header wegzulassen. Die Anfrage geht dann ohne die Vorab-Nachfrage raus und der Zielserver nimmt den Body direkt entgegen. Das ist die sauberste Lösung, wenn du keinen Einfluss auf den Zielserver oder den Proxy hast, aber deinen eigenen cURL-Code anpassen kannst.

Lösung 3: Squid und andere Proxies

Sitzt ein Squid-Proxy in der Kette, kann auch dieser den Expect-Header verschlucken oder falsch behandeln. Der Fehler landet dann im Squid-Access-Log als 417. Hier hilft es, den Proxy so zu konfigurieren, dass er mit 100-continue korrekt umgeht oder den Header entfernt. Die konkrete Direktive hängt von der Squid-Version ab. Als Einstieg lohnt der weiter unten verlinkte Beitrag, der den Fall im Squid-Access-Log ausführlich behandelt.

Grundsätzlich gilt: Egal welche Zwischenstation den Fehler verursacht, das Ziel ist immer, den Expect-Header vor dieser Station loszuwerden. Ob du das im Client (cURL), im Reverse Proxy (Apache) oder im Cache-Proxy (Squid) machst, hängt davon ab, wo du Zugriff hast.

Hintergrund: Wie 100-continue eigentlich funktioniert

Der Mechanismus stammt aus HTTP/1.1 und ist eigentlich sinnvoll gedacht. Bevor ein Client einen großen Request-Body (etwa einen Datei-Upload) überträgt, schickt er nur die Header samt Expect: 100-continue und wartet. Der Server prüft die Header - etwa ob die Authentifizierung stimmt oder der Content-Type erlaubt ist - und antwortet mit 100 Continue, wenn alles passt. Erst dann sendet der Client die eigentlichen Daten. Das spart Bandbreite, weil ein zum Scheitern verurteilter Upload gar nicht erst komplett übertragen wird.

In der Praxis mit Proxies und älteren Serverkomponenten sorgt genau dieser Zwischenschritt aber oft für Probleme. Deshalb ist das Entfernen des Headers in fast allen Fällen unkritisch: Der Upload wird dann eben in einem Rutsch übertragen, ohne die Vorab-Nachfrage. Für die meisten Anwendungen ist das völlig ausreichend.

Häufige Fragen

Was bedeutet HTTP-Statuscode 417?

417 Expectation Failed heißt, dass der Server die im Expect-Header angegebene Erwartung des Clients nicht erfüllen kann. In der Praxis geht es dabei fast immer um den Wert Expect: 100-continue.

Wie behebe ich den 417-Fehler am schnellsten?

Entferne den Expect-Header. Im Apache-Reverse-Proxy mit "RequestHeader unset Expect early", in PHP cURL mit curl_setopt und einem leeren Expect-Eintrag. Danach läuft die Anfrage normal durch.

Ist es riskant, den Expect-Header zu entfernen?

In den allermeisten Fällen nein. Der Client überträgt seinen Request-Body dann einfach direkt, ohne die Vorab-Nachfrage. Nur bei sehr großen Uploads über langsame Verbindungen kann die Bandbreitenersparnis von 100-continue relevant sein.

Warum tritt der Fehler erst nach einem Server-Update auf?

Updates ändern häufig das Standardverhalten von Proxy- oder Server-Modulen. Eine neuere Version behandelt den Expect-Header dann strenger als vorher, wodurch der 417-Fehler plötzlich auftaucht, obwohl sich am Client nichts geändert hat.