HTTP 400

Last change on 2025-05-06 • Created on 2025-05-06 • ID: ST-B80E5

Wenn Sie unerwartet einen HTTP-400-Fehler erhalten, könnte dies verursacht werden durch:

Inaktivität

Das Hochladen großer Datenmengen kann mehrere Minuten dauern. Um eine aktive Verbindung aufrechtzuerhalten, müssen kontinuierlich Daten übermittelt werden, auch wenn nur eine sehr geringe Datenmenge übertragen wird. Wenn der Client inaktiv ist, das heißt 15 Sekunden oder länger keine Daten gesendet hat, wird die Verbindung automatisch beendet.

Mögliche Ursachen für Inaktivität:

Ursache Beschreibung
Zwangstrennung Manche Internetanbieter erzwingen eine regelmäßige Trennung vom Internet (z.B einmal pro Tag).
Instabile Internetverbindung Wenn Sie vorübergehend kein Netz mehr haben, wurde der Upload unter Umständen bereits beendet, bevor die Verbindung wiederhergestellt werden konnte.
Geplante Wartung oder Updates Systemupdates können Netzwerkdienste unterbrechen.
Firewall Wenn Firewall-Einstellungen während einer aktiven Verbindung geändert werden, kann dies dazu führen, dass bestimmter Datenverkehr blockiert wird.
Fehlkonfiguration des Routers Wenn Sie ein privates Gerät mit einem Router verwenden, können falsche Einstellungen dazu führen, dass der Router Verbindungen unerwartet trennt.

Falscher Host-Header

Wenn Object Storage eine Anfrage erhält, muss der Host-Header – also der angeforderte Domainname – der Bucket-Domain entsprechen. Wenn im Host-Header eine Domain angegeben ist, die nicht der Bucket-Domain entspricht, wird die Anfrage verworfen.

Gängige Tools wie der MinIO Client und die AWS CLI setzen den Host-Header standardmäßig auf die Bucket-Domain.

Wenn Sie jedoch einen eigenen Client oder eine eigene Domain (siehe den FAQ-Eintrag "Kann ich einem Bucket eine eigene Domain / CNAME zuweisen?") verwenden, kann es passieren, dass in der Anfrage der falsche Host-Header angegeben wird.

  • Eigener Client

    Um zu prüfen, ob das Problem mit dem Host-Header zusammenhängt, benötigen Sie die Header, die Ihr Client mit der Anfrage sendet. Ihr Client muss dafür eine Möglichkeit bieten, Debug-Informationen auszugeben, zum Beispiel über eine Flag wie --debug. Mit der AWS CLI würde es beispielsweise so aussehen:

    holu@example:/$ aws s3api get-object --debug --bucket <bucket_name> --key <object_name> <local_target_location>
[...]
GET
/<object_name>

host:<bucket_name>.fsn1.your-objectstorage.com
x-amz-content-sha256:<hash>
x-amz-date:<date>
[...]

    In dem oberen Beispiel wird in der Anfrage der richtige Host-Header angegeben — die Bucket-Domain. Wenn in Ihrem Output eine andere Domain angegeben ist, die nicht der Bucket-Domain entspricht, bestätigt das, dass Ihr Problem mit dem Host-Header zusammenhängt. In diesem Fall sollten Sie prüfen, ob es mit dem Client, den Sie verwenden, möglich ist den Host-Header zu überschreiben.


  • Eigene Domain

    Führen Sie die folgenden beiden Befehle auf, um zu prüfen, ob der Host-Header die Ursache Ihres Problems ist:

    Ersetzen Sie example.com mit Ihrer eigenen Domain, test.txt mit einer Datei in Ihrem Bucket und <bucket_name>.<region> mit dem Namen und der Region Ihres Buckets.

    holu@example:/$ curl --insecure https://example.com/test.txt
<html><body><h1>400 Bad request</h1>
Your browser sent an invalid request.
</body></html>

holu@example:/$ curl --insecure https://example.com/test.txt -H "Host: <bucket_name>.<region>.your-objectstorage.com"
Hello World! This is the content of the test file!

    Wenn das Hinzufügen des Host-Headers Ihr Problem löst, müssen Sie den Host-Header auch in allen künftigen Anfragen überschreiben. Wenn Sie einen Reverse Proxy verwenden, können Sie den Host-Header direkt in der "Reverse Proxy"-Konfiguration ergänzen (z.B. mit NGINX). Wenn Sie einen CNAME-Record verwenden, hilft eventuell das How-To "Eigene Domain mit CNAME", das anhand von zwei Beispielen erklärt, wie man den Host-Header ändern kann.