Fehler 405 bei einem Link: HEAD und GET vergleichen

Einen Link nicht allein wegen der Zahl als defekt einstufen

Dein Browser öffnet eine Seite, eine Prüfung meldet jedoch 405. Dieser Unterschied erfordert eine Untersuchung statt sofortiger Löschung des Links. Laut empfangener Antwort wird die angeforderte Methode für diese Ressource nicht unterstützt. Daraus folgt weder, dass der Inhalt existiert, noch dass er öffentlich oder für jeden Besucher verfügbar ist. Bewahre die genaue Adresse auf und notiere das verwendete Prüfwerkzeug.

Eine Frage auf Stack Overflow beschreibt 405 nach dem Wechsel einer Prüfung von GET zu HEAD. Eine weitere Frage auf Reddit behandelt Fehlalarme eines Linkprüfprogramms. Diese Berichte belegen nicht die Ursache deines Falls. Dieser Ablauf vergleicht Anfragen und kontrolliert den Inhalt, bevor entschieden wird, ob Link, Prüfprogramm oder Website-Konfiguration korrigiert werden müssen.

Was HEAD und GET unterscheidet

GET fordert eine Darstellung der Ressource an; HEAD fordert die zu GET gehörenden Metadaten ohne den Antwortinhalt an. MDN erläutert diesen Unterschied. Nur Header anzufordern kann Übertragung sparen, liest aber weder die Seite noch bestätigt es das erwartete Dokument. Ebenso wenig garantiert es, dass eine Anwendung oder Zwischenstation beide Methoden korrekt behandelt. Halte bei einer Ablehnung deshalb die tatsächlich verwendete Methode fest.

RFC 9110 verlangt bei 405 einen Allow-Header mit den aktuell unterstützten Methoden der Ressource. Prüfe ihn, falls dein Werkzeug ihn anzeigt. Fehlt er, dokumentiere das; erfinde keine Werte und nimm nicht an, dass die Freigabe sämtlicher Methoden das Problem lösen würde. Die Beispielantwort ist illustrativ und stammt von keiner echten Website. Allow ersetzt die Prüfung der benötigten Methode nicht.

HTTP/1.1 405 Method Not Allowed
Allow: GET

Verständliche Anfragen vergleichen

Wenn du die Website verwaltest und mit einem Terminal umgehen kannst, vergleiche HEAD und GET für dieselbe öffentliche Leseadresse. Die Befehle zeigen Header; der zweite verwirft den Inhalt erst nach dem Empfang und kann daher Daten herunterladen. Ersetze example.invalid durch deine autorisierte Seite. Die Domain ist fiktiv, kein verfügbarer Prüfdienst. Verwende keine Kauf-, Lösch- oder Abmeldeaktionen als Testziel.

Halte URL und beeinflussbare Bedingungen gleich. Notiere Zeitpunkt, Methode, Status und mögliche Weiterleitung. Die Befehle folgen Weiterleitungen nicht: Prüfe deren Ziel zuerst und entscheide dann über eine Wiederholung dort. Übertrage weder Zugangsdaten noch private Cookies an öffentliche Werkzeuge. Ein angemeldeter Browser und eine anonyme Anfrage von einem anderen Rechner sind kein gleichwertiger Vergleich. Dokumentiere solche Unterschiede, bevor du die Methode verantwortlich machst.

curl --head --max-time 20 "https://example.invalid/guide"
curl --silent --show-error --max-time 20 --dump-header - --output /dev/null "https://example.invalid/guide"

Ergebnisse ohne voreilige Schlüsse einordnen

Erhält HEAD unter vergleichbaren Bedingungen 405 und GET 200, steht zunächst nur fest, dass beide Anfragen unterschiedliche Antworten bekamen. Öffne zusätzlich die Seite und prüfe den Inhalt. Liefert auch GET 405, ist kein ausschließliches HEAD-Problem nachgewiesen. Liefert GET 404, hat die vorherige HEAD-Prüfung die Existenz der gewünschten Seite nicht bewiesen. Trenne jede Beobachtung ausdrücklich von deiner Vermutung.

Stelle ein Formular nicht von POST auf GET um, nur um die Fehlermeldung zu beseitigen. Das kann seine Funktion verändern und Daten in der Adresse offenlegen. Deaktiviere weder Schutzmaßnahmen noch aktiviere Schreibmethoden aus Bequemlichkeit. Bei einer eigenen Website erhält die zuständige Person die Ergebnisse zur Prüfung der Routen und Serverregeln. Bei fremden Websites bitte um einen geeigneten öffentlichen Link oder melde den Fehler ohne sensible Daten.

Eine WikiURL-Prüfung ergänzen

Füge die vollständige öffentliche Adresse in den URL-Prüfer von WikiURL ein und speichere HTTP-Status sowie erkanntes Endziel. Dies ist eine zusätzliche Beobachtung vom Server des Dienstes. Sie bildet deinen Browser, deine Sitzung oder die vorherigen Befehle nicht zwingend nach. Die Oberfläche bietet keine manuelle Auswahl zwischen HEAD und GET. Schreibe ihr daher keinen Methodenvergleich zu, den sie nicht anzeigt.

Öffne anschließend das echte Ziel im Browser und kontrolliere, ob die vorgesehene Zielgruppe die erwartete Seite erhält. Weichen Prüfer und Browser ab, bewahre beide Ergebnisse samt Bedingungen auf. Ein 200 bestätigt weder Inhalt noch Sicherheit; ein einzelner 405 entscheidet nicht über das Entfernen des Links. Sammle Belege für die Korrektur des konkreten Bestandteils, statt eine Anzeige als vollständige Diagnose zu behandeln.

Vor dem Teilen eine überprüfbare Entscheidung festhalten

Erstelle ein kurzes Protokoll: URL, Datum, Werkzeug, bekannte oder nicht beobachtete Methode, Status, Endziel und geprüfter Inhalt. Fehlende Prüfungen bleiben als offen markiert. Bewahre erforderliche Header ohne Tokens, Cookies oder persönliche Daten auf. Andere Prüfende benötigen diese Zusammenfassung und das erwartete Verhalten, keine Schlussfolgerung, die von den Beobachtungen noch nicht getragen wird.

Wiederhole nach einer konkreten Korrektur eine angemessene Prüfung und bestätige den Inhalt, bevor du die Adresse mit WikiURL kürzt oder einen QR erzeugst. Diese Formate vereinfachen das Teilen, ändern aber keine unterstützte Servermethode und reparieren keine Ressource. Bewahre den Referenzlink bei der veröffentlichten Datei auf. So unterscheidest du Client-Unterschiede, abgelehnte Methoden und falsche Ziele, ohne eine gültige Adresse wegen einer einzigen Antwort aufzugeben.