Unsauberes Verhalten

Ich habe die KI befragt, ob sie dieses Verhalten auch für Unfug hält.

Gemini Anfrage

Ich:

Hallo, wenn ich das Impressum von lebensmittelwarnung per GET-request abrufe, kommt
200 OK
So weit, so gut.

per HEAD kommt
HTTP/1.1 303 See Other
und
Location: /error_path/400.html

Das ist doch Unfug - oder?

Gemini Antwort

Gemini:
Das ist in der Tat streng genommen unsauber, aber ein typisches Verhalten, wenn eine Web Application Firewall (WAF) oder ein Load Balancer (hier deutet AL_BALANCE-S auf einen Application Level Balancer hin) dazwischenfunkt.

​Dass der Server bei HEAD mit 303 See Other und einer Umleitung auf 400.html antwortet, hat in der Praxis meist folgende Gründe:

​WAF/Bot-Protection unterscheidet HTTP-Methoden: Viele WAFs sind so konfiguriert, dass sie nur GET (und evtl. POST) standardmäßig durchlassen. Seltenere Methoden wie HEAD, OPTIONS oder TRACE werden aus Sicherheitsgründen pauschal geblockt oder abgefangen, um automated Scans abzuwehren.

• ​Fehlende User-Agent-Behandlung bei HEAD: Bei curl -I schickt cURL einen sehr minimalistischen Request. Manche WAFs stufen Anfragen ohne vollständige Browser-Header in Kombination mit HEAD als Scraping/Scanner ein und leiten auf eine Fehlerseite um.
• ​Server- / CMS-Fehlkonfiguration: Das zugrunde liegende CMS (oft Government-Standard-Systeme auf Apache-Basis) verarbeitet HEAD-Requests nicht sauber auf Applikationsebene. Der Server versucht dann intern eine Umleitung, was die WAF wiederum als fehlerhaften Request interpretiert und zur Fehlerseite schickt.

​Dass dabei ausgerechnet ein 303 (See Other) in Kombination mit einem Ziel-Pfad 400.html (Bad Request) zurückgegeben wird, ist semantisch vollkommener Quatsch: Ein 400er-Fehler sollte direkt als Statuscode geliefert werden und nicht per 303-Umleitung. Das ist ein klares Indiz für ein zusammengebasteltes Fehlerhandling der Firewall.