• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

Apache-Headers aus .htaccess mit PHP-Headers überschreiben?

G

Gelöschtes Mitglied 35303

Guest
Hallo,
Teile meiner Website kann man nur über "Umwege" erreichen. Das ist so gewollt und so soll in dieser Frage auch nicht auf Alternativen bezüglich dieses Vorgehens hingewiesen werden.

Konkret geht es darum, dass der Nutzer einen Pfad meiner Website aufruft (beispielsweise: https://www.example.com/path/to/index.php). Da diese Pfade aber in der Regel nicht existieren, wird ein HTTP-Status 404 erzeugt. Diesen fange ich mit meiner .htaccess-Datei ab (mittels errorDocument) und leite die Anfrage an die index.php weiter. Die index.php sucht nun nach den angefragten Inhalten und soll - sofern welche gefunden werden - diese ausgeben sowie den HTTP-Status 404 mit einem HTTP-Status 200 ersetzen.
In meinen Versuchen hat der Nutzer aber trotzdem den Status 404 in dem Response-Header erhalten.

Code: 
<?php
header("HTTP/2.0 200 OK");
Code: 
errorDocument 404 /index.php?path=%{REQUEST_URI}

Ist es irgendwie möglich, den Apache-Header zurückzunehmen/"aufzufangen" und durch den PHP-Header zu ersetzen?

Vielen Dank für Eure Hilfe :)
 
Die Verwendung von http_response_code() schließt die Verwendung von header() aber nicht aus, oder? Also ich sollte zur Sicherheit trotzdem beide Methoden aufrufen?

Trotz Aufruf von http_response_code() hat die Response den Code 404.
 
Okay, ich hab's nochmal versucht; hat leider nicht funktioniert:
http_response_code() liefert zwar 200, überschreiben lässt sich das ganze mit http_response_code(200) aber leider nicht. Mein Browser zeigt mir nach wie vor die 404 an.

Welchen Ansatz könnte ich stattdessen verfolgen?
 
Was steht in der .htaccess-Datei? Welche URL rufst Du auf und wieso sollte diese statt einem 404 einen 200er bringen?
 
  • .htaccess-Datei: siehe Code im ersten Post
  • URL: eine Beliebige Domain, die es im Dateisystem an sich nicht gibt
  • Sinn: Der eigentlich Content liegt außerhalb des Document Root. Im Document Root liegt einzig und allein eine index.php, die dazu dient, die Anfragen zentral auszuwerten, was mir mehr Kontrolle über die Zugriffe verschafft.
 
Eine Domain, die es im Dateisystem nicht gibt? Oo

Verwende mal statt dem ErrorDocument mod_rewrite:
Code: 
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* /index.php?path=%{REQUEST_URI} [L]
 
threadi schrieb:
Eine Domain, die es im Dateisystem nicht gibt? Oo
Zum Vergrößern anklicken....

Das war von mir vielleicht etwas unglücklich formuliert, deshalb stattdessen ein Beispiel:
  • Document Root: /home/website/public_html/
  • .htaccess: /home/website/public_html/.htaccess
  • index.php: /home/website/public_html/index.php
  • Inhalte: /home/website/contents/
Ein Nutzer versucht, https://www.example.com/ein/Beispiel/ aufzurufen. Dieser Pfad existiert allerdings nicht im Document Root. Stattdessen sucht index.php nach dem Pfad im Inhalts-Ordner. Existiert dieser Pfad dort, werden die Inhalte geladen und der HTTP-Status soll entsprechend aktualisiert werden.

threadi schrieb:
Verwende mal statt dem ErrorDocument mod_rewrite:
Code: 
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* /index.php?path=%{REQUEST_URI} [L]
Zum Vergrößern anklicken....

Ist dies auch ohne zusätzlichen Parameter zu lösen? Quasi so, dass alle Anfragen an die index.php weitergeleitet werden? PHP kennt nämlich trotz ErrorDocument die angefragte REQUEST-URI.
 
Klar, den Parameter kannst Du auch weglassen. Hab ich nur so geschrieben, da Du das in deinem Entwurf stehen hattest.
 
Aber ohne mod_rewrite kann man das Problem nicht lösen, richtig?
Alle von mir getesteten Browser (Google Chrome, Mozilla Firefox, Safari, Tor Browser) liefern trotz des Aufrufs von http_response_code(200) den Fehlercode 404.
 
Das Problem ist in dem Fall die Error-Seite, die vom Apache ausgegeben wird. Denn bei ErrorDocument 404 wird exakt auch dieser HTTP-Status ausgeliefert. Die Lösung wäre daher wie gesagt mod_rewrite.
 
outsideHTML schrieb:
.....und leite die Anfrage an die index.php weiter. ...
Zum Vergrößern anklicken....
Zur Weiterleitung müsste dein Server eigentlich einen neuen Header senden. Spätestens ab hier dürfte also eigentlich kein Error mehr im Header enthalten sein!?

Ich leite per .htaccess so weiter:

Code: 
AddHandler phpXX-cgi .php
ErrorDocument 400 /error.php?nr=400
ErrorDocument 401 /error.php?nr=401
ErrorDocument 402 /error.php?nr=402
ErrorDocument 403 /error.php?nr=403
ErrorDocument 404 /error.php?nr=404
ErrorDocument 405 /error.php?nr=405
ErrorDocument 406 /error.php?nr=406
ErrorDocument 407 /error.php?nr=407
ErrorDocument 408 /error.php?nr=408
ErrorDocument 500 /error.php?nr=500
ErrorDocument 501 /error.php?nr=501
Über die error.php werte ich dann die Meldungen aus und leite entsprechend weiter. In meiner error.php ist dann kein Error-Staus mehr im response.

PS
AddHandler phpXX-cgi .php das XX durch den entsprechend passenden Eintrag ersetzen, also z.B. AddHandler php56-cgi .php o.Ä.
 
Ich verstehe nicht, wieso man den Umweg über ErrorDocument gehen muss wenn sowieso alles an die index.php geschickt werden soll?

Mit folgender .htaccess wird jede Anfrage, welche an nicht existierende Dateien geht, an die index.php gereicht:
Code: 
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
Arbeite damit und nicht mit errordocuments
 
Sentence schrieb:
Ich verstehe nicht, wieso man den Umweg über ErrorDocument gehen muss wenn sowieso alles an die index.php geschickt werden soll?
....
Arbeite damit und nicht mit errordocuments
Zum Vergrößern anklicken....
Nö!

Du leitest alles weiter, was (wieso auch immer) nicht aufgelöst werden kann.
Ich leite an eine error.php weiter, analysieren den Fehler, je nach Fehler schicke ich ein Mail und kann, je nach Fehler, gezielt reagieren und gezielt weiterleiten.

Wenn dich interessiert, was auf deinem Server wieso in die Hose geht, arbeite mit ErrorDocument.
 
sysop schrieb:
Nö!

Du leitest alles weiter, was (wieso auch immer) nicht aufgelöst werden kann.
Ich leite an eine error.php weiter, analysieren den Fehler, je nach Fehler schicke ich ein Mail und kann, je nach Fehler, gezielt reagieren und gezielt weiterleiten.

Wenn dich interessiert, was auf deinem Server wieso in die Hose geht, arbeite mit ErrorDocument.
Zum Vergrößern anklicken....

Nö!

@Sentence Lösung die einzig richtige hier und es gibt daran nichts zu “nöen”.

Deine ist höchstens… akzeptabel und lässt darauf schließen dass du nicht objektorientiert programmierst, keine Design Patterns anwendest oder mindestens mal ein PHP Framework eingesetzt und analysiert hast.

Eine moderne Webanwendung “empfängt” alle dynamischen Anfragen via Front Controller und entscheidet dann wie auf diese Anfrage reagiert werden soll.

Ob also eine Route nicht gefunden wird, entscheidet die Webanwendung. Nicht irgendein Webserver, der gar keine Ahnung von der Anwendungslogik.
 
Ich habe jetzt Eure verschiedenen Versionen ausprobiert und halte die Lösung von @Sentence am besten. Ich habe diese jedoch so modifiziert, das jegliche Anfragen an die index.php weitergeleitet werden.

Vielen Dank an alle, die zu dem Thema beigetragen haben :)
 
.htaccess -> OOP?

scbawik schrieb:
Nö!

@Sentence Lösung die einzig richtige hier und es gibt daran nichts zu “nöen”.
....
Zum Vergrößern anklicken....
Doch gibt es und zwar einiges!
scbawik schrieb:
Ob also eine Route nicht gefunden wird, entscheidet die Webanwendung. Nicht irgendein Webserver, der gar keine Ahnung von der Anwendungslogik.
Zum Vergrößern anklicken....
Die Webanwendung weiss in diesem Fall überhaupt nicht dass die Route nicht gefunden wurde oder ob die Anfrage eine reguläre oder eine umgeleitete ist. Genau genommen bekommt die Webanwendung hier immer eine reguläre Anfrage, da sie von einer ursprünglichen Fehlerumleitung keine Ahnung hat.
Die Anwendung interessiert es in diesem Fall nicht, ob der Server gerade ausgelastet ist oder könnte bei einer permanent verschobenen Datei eventuell eine Alternative bieten, weiss aber nicht, dass die Datei verschoben ist, weil sie den Stratuscode des response headers nicht hat.

Bei einem Fehler wird einfach die Startseite ausgegeben, ok, geht auch, hat aber im vorliegenden Fall mit einer Anwendung, die entscheidet, null und nichts gemein.

Die error.php, die je Statuscode Alternativen bietet, bei einem Statuscode 102 z.B. ein reload (Neuaufbau der Daten) verhindert, bei 408 einen Hinweis ausgibt dass möglicherweise noch Daten fehlen und je nach Anfrage z.B. einen Download als zip anbietet und bei einem Status 415 den Medientypen erneut prüft kommt dem schon näher. Ob ich das nun Objektorientiert, strukturiert oder über Spaghetticode mache ist der error.php vollkommen egal. Entscheidend ist, dass der Fehler bekannt ist und je Fehler entschieden wird.
Welche Lösung zu wählen ist, hängt also lediglich davon ab, wie flexibel und sicher man seine Anwendung machen möchte und wie flexibel und sicher die Fehlerbehandlung sein soll.

Um mittels PHP einen Download zu starten bedient man sich ja auch der header, nur sendet man sie bewusst, wieso sollte man sie nicht bewusst auswerten?

Die Frage war, ob man den header nach dem Versandt umschreiben kann.
Nein, wurde der response header an die index.php gesandt, steht er in der index.php und kann nicht wieder geändert werden.
Der Fehler lag darin, den Status direkt an die index.php zu übergeben und keine Anwendung dazwischen zu schalten und dort je nach Statuscode bewusst umzuleiten, mail zu senden, Cronjob zu starten, Backup zu machen, den Server herunter zu fahren oder eben auch gezielt auf die index.php umzuleiten.
 
Zuletzt bearbeitet:
sysop schrieb:
.htaccess -> OOP?


Doch gibt es und zwar einiges!

Die Webanwendung weiss in diesem Fall überhaupt nicht dass die Route nicht gefunden wurde oder ob die Anfrage eine reguläre oder eine umgeleitete ist. Genau genommen bekommt die Webanwendung hier immer eine reguläre Anfrage, da sie von einer ursprünglichen Fehlerumleitung keine Ahnung hat.
Die Anwendung interessiert es in diesem Fall nicht, ob der Server gerade ausgelastet ist oder könnte bei einer permanent verschobenen Datei eventuell eine Alternative bieten, weiss aber nicht, dass die Datei verschoben ist, weil sie den Stratuscode des response headers nicht hat.

Bei einem Fehler wird einfach die Startseite ausgegeben, ok, geht auch, hat aber im vorliegenden Fall mit einer Anwendung, die entscheidet, null und nichts gemein.

Die error.php, die je Statuscode Alternativen bietet, bei einem Statuscode 102 z.B. ein reload (Neuaufbau der Daten) verhindert, bei 408 einen Hinweis ausgibt dass möglicherweise noch Daten fehlen und je nach Anfrage z.B. einen Download als zip anbietet und bei einem Status 415 den Medientypen erneut prüft kommt dem schon näher. Ob ich das nun Objektorientiert, strukturiert oder über Spaghetticode mache ist der error.php vollkommen egal. Entscheidend ist, dass der Fehler bekannt ist und je Fehler entschieden wird.
Welche Lösung zu wählen ist, hängt also lediglich davon ab, wie flexibel und sicher man seine Anwendung machen möchte und wie flexibel und sicher die Fehlerbehandlung sein soll.

Um mittels PHP einen Download zu starten bedient man sich ja auch der header, nur sendet man sie bewusst, wieso sollte man sie nicht bewusst auswerten?

Die Frage war, ob man den header nach dem Versandt umschreiben kann.
Nein, wurde der response header an die index.php gesandt, steht er in der index.php und kann nicht wieder geändert werden.
Der Fehler lag darin, den Status direkt an die index.php zu übergeben und keine Anwendung dazwischen zu schalten und dort je nach Statuscode bewusst umzuleiten, mail zu senden, Cronjob zu starten, Backup zu machen, den Server herunter zu fahren oder eben auch gezielt auf die index.php umzuleiten.
Zum Vergrößern anklicken....

Auch wenn ich nach mehrmaligem durchlesen nur die hälfte verstanden habe, liegst du weiterhin falsch.

Warum sollte ein response header an die index.php gesendet werden? Das ist ja das was ich kritisiere. Du jonglierst hier responses und requests hin und her anstatt einen sauberen application flow zu erzeugen.

@Sentence .htaccess leitet alle requests die keiner datei zugeordnet werden können an die index.php weiter, wo diese via php verarbeitet werden können.

Die index.php ist dabei nur der einstiegspunkt der Anwendung. Das hat nichts mit der Startseite zu tun. Dort wird die App gebootet, welche dann die request verarbeitet und response inkl. status codes liefert.
 
scbawik schrieb:
Die index.php ist dabei nur der einstiegspunkt der Anwendung. Das hat nichts mit der Startseite zu tun. Dort wird die App gebootet, welche dann die request verarbeitet und response inkl. status codes liefert.
Zum Vergrößern anklicken....
Jedes MVC Framework arbeitet auf diese weise.
Erst ein Errorcode abzufangen und dann zu verarbeiten und am besten noch was anderes draus machen ist doch mist und für mich auch völlig unvrständlich warum man das so machen sollte.
Ich arbeite nun schon seit 18 Jahren (Gott bin ich alt) in der Entwicklung, aber sowas ist mir bisher noch nicht unter die Augen gekommen.

MfG
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neueste Beiträge

Zurück
Oben