Hallo,

Alte IE hatten die Default-Einstellung, 404-Fehlerdokumente des Servers zu unterschlagen, und stattdessen ihre eigene Meldung anzuzeigen.
Und irgendeinen generellen Zusammenhang zwischen der Größe des Fehlerdokumentes gab’s in älteren IE auch noch – IIRC haben sie es sogar ignoriert, wenn der Nutzer das explizit abgestellt hatte, und das Fehlerdokument kleiner als 512 Byte war.

IIRC war es genau umgekehrt: Ab einer Länge des Error-Dokuments von 512 Byte hat der IE dem Server "geglaubt" und dessen Dokument angezeigt, darunter nur, wenn der Nutzer es mit der Einstellung "Kurze HTTP-Fehlermeldungen anzeigen" explizit gefordert hat. Das betraf auch nicht nur den Status 404, sondern auch andere Fehlerbedingungen, etwa 403 oder 500.

Ist das denn bei aktuellen IE-Versionen inzwischen anders?

Wenn du irgendeinen *relevanten* Inhalt verbreiten willst – dann *lüge* nicht bezüglich seines Status, das ist einfach Unsinn.

Genau. Es spricht aber nichts dagegen, den Status 404 zu senden, dem menschlichen Nutzer aber trotzdem irgendeine Hilfe anzubieten, etwa eine Liste von Links zu möglichen Alternativen, ein Suchformular, oder auch die Startseite der Website (das hatten wir hier neulich als Diskussionsthema).

Ciao,
 Martin

Ich möchte ein script (php) verwenden aber der Aufruf soll 404 zurückliefern (genau als wäre nichts da), außer es erfolgte eine korrekte Anmeldung.

Security by Obscurity also – wozu? Dass das Unfug ist, sollte doch klar sein.

Die Security kommt von der Anmeldung. Obscurity betrifft nur daß nicht zu sehen sein soll, daß überhaupt was da ist.

Wenn du irgendeinen *relevanten* Inhalt verbreiten willst

Relevanter Inhalt kann ein Anmeldeformular sein, welches nur für mich oder noch ganz wenige andere Leute gedacht ist. Wenn also was nicht funktionieren würde, würde ich das schon merken, ich wollte mich nur im Vorfeld informieren.

dann *lüge* nicht bezüglich seines Status, das ist einfach Unsinn.

Mir geht es um einen die Regel bestätigenden Ausnahmefall. Und robots.txt und noindex wird auch benutzt, auch wenn es vor nichts sicher schützt. Vor manchem auch nicht bei guten Bots.

hi,

Wenn der Nutzer nicht berechtigt ist, auf eine Ressource zuzugreifen – dann antworte mit einem *passenden* Statuscode – entweder 403 Forbidden, oder 401 Unauthorized (letzteres nur wenn auch tatsächlich sowas wie HTTP Auth verwendet wird).

Bitte nicht verwechseln: Authentifizierung, Autorisierung

Einen Header für nicht autorisierte Benutzer gibt es nicht. Es gibt jedoch einen Header für nicht authentifizierte Benutzer.

Es ist möglich, den Request auf eine autorisierte Ressource an eine dem Request vorhergehende Autentifizierung zu koppeln und für Letzteres einen dementsprechenden Header zu senden (Auth Basic). Es ist jedoch nicht zwingend vorgeschrieben, Auth Basic zu benutzen.

D.h., wenn es eine Ressource gibt, die nur einem dafür autorisierten Benutzerkreis zugänglich sein soll, musst Du das nicht mit einem Auth Basic Header kundtun.

Horst

Ok, dann werde ich es so machen wie es mir vorschwebte, danke.

Diese Frage verstehe ich leider nicht. Kannst du sie umformulieren?

Das war ergänzend noch mal die gleiche Frage, nur mehr aus Sicht der Nutzung/Motivation und etwas ergebnisoffener.

Ich möchte ein script (php) verwenden aber der Aufruf soll 404 zurückliefern (genau als wäre nichts da), außer es erfolgte eine korrekte Anmeldung.

Mal zurückgefragt: Autorisierte Benutzer sollen andere Inhalte sehen, ggf. auch auf einunddemselben URL andere Inhalte

Ja, oder jein, abhängig von der Formulareingabe (nach der Anmeldung) wird das Verarbeitungsergebnis variieren.

(je nach Benutzergruppe), ist das Dein Anliegen bzw. Ziel?

Das könnte sich in Zukunft auch ergeben, ja. (zeitlich und "grupplich" sehr beschränkter Umfang)