Wie man einen falschen bzw. nicht existierenden Link innerhalb einer Domain mittels .htaccess abfängt und umleitet ist ja hinreichend bekannt. Leider konnte ich keine Info darüber finden, ob und wie es möglich ist, an Infos über den falschen bzw. nicht existierenden Link heranzukommen, d.h. was haben denn die Leute denn eigentlich falsch eingegeben? Wie geht das bzw. wo finde ich Infos dazu? Danke für Tips.
HTTP_REFERER ?
Gast
#5964586
Frank E. schrieb: > was haben denn die Leute denn eigentlich falsch eingegeben I.A. nichts, sondern er hat bloss eine extern gespeicherte veraltete URL angeklickt, und der Trottel von WebEntwickler hat in der Strukturierung seiner WebSite Fehler gemacht und sie daher zur Fehlerbehebung umstrukturiert und die URL unter der die Seite nun erreichbar ist verändert ohne dass ein Redirect ausgelöst wird. Besonders gerne passiert das beim Merge von Firmen und damit WebSites, aber auch im täglichen Geschäft dummer WebEntwickler. Merke: JEDE Änderung einer URL ohne redirect ist ein Nachlässigkeitsfehler des WebEntwicklers.
Joachim D. schrieb: > HTTP_REFERER ? Das ist, wenn nicht leer, die Adresse der Seite, in der der falsche Link enthalten ist. Ok, man könnte dort nachsehen. Ich habe inzwischen weiter recherchiert und bin auf "$_SERVER[REQUEST_URI]" gestossen. Da sollte das nicht existierende Ziel drin stehen. Bin aber noch nicht zum ausprobieren gekommen ...
Gast
#5964604
Ich mach das bei meiner Seite so, um zu loggen, wenn eine fehlende Seite aufgerufen wird (PHP):
1 | |
2 | |
3 | |
4 | |
Böderweise enthält auf meinem Server das Array-Element
$_SERVER['REQUEST_URI'] nur die eigene Fehlerseite "error.php" aber
nicht, wie erhofft, den falschen Aufruf. Irgendwie witzlos :-(
Nachtrag: Erledigt.
Allerdings musste ich bereits in der vorgelagerten .htaccess Hand
anlegen. Dort hats geholfen, die Variable {REQUEST_URI} als Parameter an
den Aufruf der error.php anzuhängen. Dann schafft es dies Info bis zu
meiner Fehlerbehandlung (inkl. GET-Parametern!). Ist wohl von der
Server-Konfiguration abhängig.
Inhalt .htaccess:1 | |
Gast
#5969568
Ich muß jetzt schon mal blöd fragen... Hat denn wirklich keiner von Euch Zugriff auf das stinknormale access/error Log vom Apache (oder Nginx)? Da steht jeder Request drin, zusammen mit dem Statuscode und noch mehr Info. Ein einfacher grep nach " 404 " und man hat eine Liste aller nicht gefundenen URLs. Simpler geht's nicht.
bofh schrieb: > Ich muß jetzt schon mal blöd fragen... > > Hat denn wirklich keiner von Euch Zugriff auf das stinknormale > access/error Log vom Apache (oder Nginx)? > > Da steht jeder Request drin, zusammen mit dem Statuscode und noch mehr > Info. Ein einfacher grep nach " 404 " und man hat eine Liste aller nicht > gefundenen URLs. Simpler geht's nicht. Ja klar, taugt aber nur zum Nachgucken. Liegt bei mir als "access_log_datum.gz". Wie soll ich das live auswerten? Mit dem direkten Zugriff über error.php ist das 100mal einfacher, WENN es denn funktioniert ... aber das tut es ja nun (bei mir).
Gast
#5969577
404notFound schrieb: > https://www.xxx.com/yyy/error.php/?url=%{REQUEST_URI} > > hihi HILFÄ!!! ADMIN!!! Kann man da noch ein XYZ draus machen? SORRY!
Gast
#5969594
Frank E. schrieb: > Ja klar, taugt aber nur zum Nachgucken. Liegt bei mir als > "access_log_datum.gz". Wie soll ich das live auswerten? Via ssh mit tail -f und grep Einfach einen richtigen Server nutzen :)
Gast
#5969599
Frank E. schrieb: > Ja klar, taugt aber nur zum Nachgucken. Liegt bei mir als > "access_log_datum.gz". Wie soll ich das live auswerten? darf man fragen wozu live? bzw. wenn die seite so groß und/oder wichtig ist, dann sollte auch jemand da sein der mit dem server auch umgehen/ihn betreuen kann. für eine hobby seite ist die live überwachung doch komplett fürn hugo (oder eine spielerei ohne tieferen sinn)...
wos woas denn i schrieb: > Frank E. schrieb: >> Ja klar, taugt aber nur zum Nachgucken. Liegt bei mir als >> "access_log_datum.gz". Wie soll ich das live auswerten? > > darf man fragen wozu live? Ich habe ja nun die URLs der ursprünglich aufgerufenen (nicht existierenden) Seiten samt Parametern. Live brauche ich sie deshalb, weil die Seitenaufrufe - je nach URL und Parametern - unterschiedlich verteilt werden sollen. Da schwirren auf Prospekten 'ne Menge falsch gedruckte QR-Codes in der Gegend herum, die nicht wieder zurückgeholt werden können, bei denen aber zum Glück wenigstens die TLD stimmt. Das kann ich nun parieren, als wäre Nichts gewesen.
Gast
#5970703
Frank E. schrieb: > Ich habe ja nun die URLs der ursprünglich aufgerufenen (nicht > existierenden) Seiten samt Parametern. Live brauche ich sie deshalb, > weil die Seitenaufrufe - je nach URL und Parametern - unterschiedlich > verteilt werden sollen. mir erschließt sich immer noch nicht warum das dann live sein muss, aber egal - du wirst schon wissen was du willst. sobald der 404er im log file aufschlägt ist es eh schon zu spät - der besucher hat gesehen, dass da nix sinnvolles kommt
wos woas denn i schrieb: > sobald der 404er im log file aufschlägt ist es eh schon zu spät - der > besucher hat gesehen, dass da nix sinnvolles kommt Wieso, es zwingt dich doch keiner eine statische Fehlerseite anzuzeigen.
Ich kann die falschen Links per PHP auswerten. Deshalb ist es mir nun möglich, bestimmte dieser falschen Links gezielt an das eigentlich vorgesehene Dokument weiterzuleiten. Das ist natürlich nur bei ganz konkreten "falschen" Links notwendig, nicht bei jedwedem Unfug. Die einen bekommen nun keinen 404-Error mehr zu sehen, die anderen schon ...
wos woas denn i schrieb: > sobald der 404er im log file aufschlägt ist es eh schon zu spät - der > besucher hat gesehen, dass da nix sinnvolles kommt Dazu kommt es garnicht mehr. Wird per .htaccess abgefangen, per PHP ausgewertet und flexibel darauf reagiert. Die Fehler, um die es hier geht, sind keine zufälligen (z.B. Vertipper etc.), sondern systematische, aus falsch hergestellten QR-Codes.