Ideale .htaccess Datei

[Synonym]

Natürlich kannst Du die löschen, die gibt es ja eh nicht. Ist Zeile 15 und 16. Musst nur bedenken, dass bei den beiden bisher immer die Startseite aufgerufen wurde. Wirklich cachen kann man die auch nicht, da de dynamische Elemente hat und auch, dass die beiden Zeilen auf jeder Unterseite stehen. Also das ist schon ein Punkt bezüglich unnötigen Traffik. Min 70 Kb für die Seite, wenn es dumm läuft 2x, da es beide nicht gibt und wenn es ganz dumm läuft noch mehr, weil dann auch die Bilder und Scripte abgefragt wurden.

Edit: Mork hatte es ja schon gesagt. Brauchst Du die jquery wirklich? Und dazu dann auch noch die mootools? Reicht da nicht eine von beiden aus?

Edit2: Warum übertragst Du eigentlich auf der Startseite bei den Bilder die aktuelle Cursorposition mit? Hat das einen speziellen Grund? z.B.
https://anglerzeitung.de/index.php?arti ... 8,43?67,55
https://anglerzeitung.de/index.php?arti ... ,43?123,53

Warum nicht einfach:
https://anglerzeitung.de/index.php?article_id=328

[domainsnake]

Da kann ich leider net so viel zu sagen, weil ich von programmieren keine Ahnung habe. Vor kurzem wußte ich nicht mal das es besagte Scripte überhaupt auf meiner Seite gibt. Das muß ich später dem Programmierer weiterleiten. Damit ichs nicht vergeß hab ich das auch in die To Do Liste integriert.

Was ihr da so alles rauslesen könnnt. Krass. Ich vermute mal das es mit dem automatischen ausloggen aus dem Membersystem zu tun hat. Bewegt sich der Cursor längere Zeit nicht, dann fliegt man aus dem Membersystem automatisch raus.

[Mork vom Ork]

Habs eben ausprobiert, wenn ich da www.anglerzeitung.de/ rausnehme, dann kommt ne 500er Errormessage

Putzig, RewriteRule ^([0-9]*)-([0-9]*)- index.php?article_id=$1&clang=$2&%{QUERY_STRING} funktioniert bei mir. Schau ins Fehlerprotokoll, eine genauere Ursache wird dort vermerkt.

Ok, meine Homepageadresse nehm ich da raus. Was bewirkt die Zeile überhaupt?

Du meinst obige Zeile? Damit wird ein Aufruf der Seite 123-456-irgendwas in einen Aufruf des Skriptes index.php mit den Parametern article_id=123 und clang=456 geändert. Sowas macht man normalerweise serverintern, damit der Besucher davon nichts mitbekommt. Aus diesem Grund ist auch die Domain überflüssig, für interne Anfragen braucht es keine Domain.

Die Statistik nennt sich von Confixx Awstats oder so und beinhaltet wirklich viele Statistiken

awstats ist ein bekanntes Analysewerkzeug und verarbeitet einzig das Zugriffsprotokoll. Dass das etwas mit der robots.txt zu tun haben soll, mag ich nicht so recht glauben, aber das wird sich auch noch klären.

212.172.221.7 - - [03/Nov/2009:01:57:30 +0100] "GET /files/2009_04_25_04_05_59__1.jpg HTTP/1.0" 200 11726 "-" "-"

Das hat sich ja jetzt geklärt, denke ich :)

[Bauchladen]

Dein traffic hat, wie schon in deinem anderen Beitrag kommentiert, seinen Ursprung in der Seite selber. Wir haben dir viele Tips zu der Optimierung dieser Seite gegeben die leider bisher nicht umgesetzt wurden.

Ich empfehle dir zunächst unsere Vorschläge bzgl. der Größenoptimierung dieser Seite zu realisieren da du ansonsten mit selbstreduzierender Tendenz mehr oder weniger immer den gleichen Antwortstapel von uns erhalten wirst bis irgendwann nichts mehr kommt.

Vergiss erst einmal die Robots, .htaccess gefummel, die HTML-Markup-Sektierer und seo. Reduziere zunächst die Größe deiner Seite. Wenn das sitzt kann man weitermachen.

Grüße

[domainsnake]

Also äh, die Antwort kann ich ja nun nicht so ohne Weiteres nachvollziehen. Sicherlich der Traffic hat seinen Ursprung in der Seite selber. Das stimmt wie ich zugeben muß. Aber vieles was hier gesagt wurde, wurde auch schon umgesetzt.

1. robots.txt Datei
2. .htaccess Datei
3. Reduzierung sämtlicher Bilddateien
Punkt 1+2 sind für mich als Nichtprogrammierer schon schwer genug gewesen. Eine Komprimierung von CSS, JS etc. wirds wie ich sagte auch noch geben. Aber das ist nicht hauptsächlich für den enormen Traffic verantwortlich. Gestern über 6 GB bei vielleicht 150 Besuchern. Selbst wenn die Startseite 1MB gross wäre, dürfte nicht so ein Traffic entstehen.

Da werden durch Scripte Bilder hin und hergeschoben, neu aufgerufen etc. Und das jede Menge. Im Code sind Fehler und die müssen jetzt gefunden werden, ansonsten muß ich die in ca. 3 Tagen erstmal vom Netz nehmen.

[Seonudel]

Mein Tip: Sag Deinem Programmierer, er soll mal Client Caching via korrekt gesetzten Headern (Stichwort Etag) "aktivieren".

Dein Logfile wird sicherlich aussagen, woher der Traffic kommt. Sowas probiert man nicht über die wahllos über die .htaccess zu fixen... da muß man tiefergehende Ursachenforschung betreiben.
Bei dem von Dir genannten Traffic wird aber sicher noch muß ein anderes Problem vorliegen. Das kann man ja grob überschlagen. Bei ca. 500KB pro Seitenaufruf (sollte noch halbiert werden) und 150 Besuchern macht das kaum 6GB Traffic. Sicher das die Zahl 150 korrekt ist?

Das die Stats nicht laufen wegen der robots.txt ist entweder ein Mythos oder Du hast den seltsamsten Hoster von dem ich bisher gehört habe. Frag mal lieber beim Support nach anstatt hier

Es gibt übrigens genug Hoster wo es unlimited Traffic gibt bzw. so viel, das Du selbst mit dem Traffic Problem nicht an eine Grenze stößt. Solltest vielleicht direkt wechseln, bevor plötzlich wirklich User kommen und Dein Hoster Dich plötzlich vom Netz nimmt...

[domainsnake]

Kurzinfo: Also einen Teilerfolg hat mein Programmierer anscheinend schon erzielt, da jetzt Bilder gecached werden. Der Aufbau der Homepage im Browser geht Ruckzuck oder zumindest deutlich schneller als sonst. Was es letztendlich gebracht hat, schauen wir morgen in den Logfiles.

Trotzdem muß noch intensiver nach Fehlern diesbezüglich gesucht werden. Wie der Ork ja auch schon sagte. Da werden Bilder nicht direkt von der Platte eingelesen, sondern über Netzwerk hin und hergeschoben ... Das läßt sich auch aus dem logfile rauslesen. Wie gesagt, da sind wir bei das rauszufinden.

Traue keiner Statistik, die du nicht selbst gefälscht hast. Also wenn ich verschiedene Besucherstatistiken auswerte, dann kommt das ungefähr hin. Selbst wenn es 200 Besucher wären, würden die 50 mehr auch net der Grund sein. Mehr sind es keinesfalls.

Ne, keine Ahnung woran das lag aber die robots.txt ist wohl net schuld. Jetzt laufen die Statistiken wieder normal.

Yep, da hatte ich mich auch schon informiert aber die Angebote sind ebenfalls mit Vorsicht zu genießen. Ist aber Unsinn, ich will lieber die Ursache weghaben, als ne Notlösung in Anspruch zu nehmen.

Es kann halt nicht immer alles glatt laufen. Ich seh das als Bereicherung, denn ich hab jetzt durch eigene Recherchen und euch sehr viel dazugelernt. Nur noch ist das Problem nicht ganz gelöst. Ich bleib am Ball.

[Bauchladen]

Also äh, die Antwort kann ich ja nun nicht so ohne Weiteres nachvollziehen.

Deine Startseite hat ein Volumen von 667KB.

Davon entfallen 405KB auf Javascript, 242KB auf Grafiken, 27KB auf HTML. Vllt. langt es schon wenn der Calendar nicht mehr auf der Startseite ist

Viel Spass dann noch!

[Mork vom Ork]

Das Beste was Du tun kannst, ist Dir schleunigst einen anderen Hoster zu suchen. Trafficgrenzen gibts nur mehr bei billigst-Hoster

Unsinn. Bei den Netzbetreibern wird immer noch nach Volumen abgerechnet und jeder Hoster, der pauschale Tarife anbietet, muss dementsprechend eine mehr oder minder riskante Mischkalkulation machen. Das führt dazu, dass a) normale Kunden für etwas bezahlen, was sie gar nicht nutzen bzw. andere verbraten, und vor allen Dingen b) jeder halbwegs fähige Hoster (lies: Kaufmann) zumindest intern doch eine Grenze festlegt - und bis jetzt wurde noch jeder Kunde, der die Kalkulation sprengt, auf die ein oder andere Art rausgeekelt.

Davon mal abgesehen hat die Kalkulation erstmal nichts mit der technischen Kompetenz zu tun. Es könnte ganz im Gegenteil so sein, dass das, was beim Pauschalpreis als Risikopuffer eingeplant werden muss, bei einem variablen Preis mit Grundvolumen in den Service gehen kann.

Kurzum, von einem Tarif mit festgelegtem Volumen auf einen schlechten Hoster zu schließen, ist reichlich weit hergeholt.

Und was das Beste angeht: Wer sich wundert, dass sein Auto so viel säuft, sollte erstmal die 500 kg Gerümpel aus dem Kofferraum entfernen und die Handbremse lösen, bevor er auf das Auto schimpft und sich einen Tankstellenpauschaltarif zulegt.

[Rem]

Keine Ahnung, ob schon wer was dazu geschrieben hat, habe den Thread nur parallel durchgelesen:

RewriteRule \.(gif|jpg|png|pdf|GIF|JPG|PNG|PDF)$ https://www.anglerzeitung.de/__extern/geklaut.gif [R,L]

Habe zuerst was von "Zirkelschluss" geschrieben, aber scheinbar nutzt Du einfach ein externes Bild. Für eine völlig interne Lösung würde ich"geklaut.gif" unter geklaut.gi2 oder so abspeichern... Das Bild wird dann dargestellt, aber nicht in der Rule erfasst.

Meine Rule sieht übrigens so aus (wobei ich einfach eine Liste an Domains angebe, die mir Bilder klauen, könnte eigentlich auch Deine Variante nehmen...)

RewriteCond %{HTTP_REFERER} ^http://(.+\.)?olom\.info/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(.+\.)?goiit\.com/ [NC]
RewriteRule .*\.(gif|GIF)$ /nohotlink.gi2 [L]

Erspart den Redirect...

[Stephan Zöllner]

Kann ich die 2 Zeilen dann nicht einfach so rauslöschen? Wenn ich sie finde?

Klar kannst Du das!
Vorrausgesetzt, daß die beabsichtigte Funktion wirklich nicht benötigt wird.

Falls die beabsichtigte Funktion weiterhin erwünscht ist wirst Du die ECHTEN Ziele / Dateien suchen und verlinken müssen.

[Synonym]

Vorrausgesetzt, daß die beabsichtigte Funktion wirklich nicht benötigt wird.

Das ist quatsch. Er kann sie löschen und fertig. Die Dateien gibt es nicht. Das hat mit benötigt oder nicht benötigt gar nichts zu tun. Was nicht da ist ist einfach nicht da und fertig.

[Stephan Zöllner]

Keine Ahnung, ob schon wer was dazu geschrieben hat, habe den Thread nur parallel durchgelesen:

RewriteRule \.(gif|jpg|png|pdf|GIF|JPG|PNG|PDF)$ https://www.anglerzeitung.de/__extern/geklaut.gif [R,L]

Das Ding stammt (indirekt) von mir!
Aber es hat ein eine kleine Vorraussetzung, damit es sinnvoll funktioniert:

Dieser Teil steht NUR in der .htaccess der Bildverzeichnisse - bei mir ist das logisch getrennt! und der Bildschutz steht NICHT im Hauptverzeichnis!

[Stephan Zöllner]

Vorrausgesetzt, daß die beabsichtigte Funktion wirklich nicht benötigt wird.

Das ist quatsch. Er kann sie löschen und fertig. Die Dateien gibt es nicht. Das hat mit benötigt oder nicht benötigt gar nichts zu tun. Was nicht da ist ist einfach nicht da und fertig.

Sei so nett und lese mal vollständig was ich geschrieben habe.
Natürlich gibt es keine Veränderung wenn er die Zeilen löscht!
ABER sie könnten mit einer bestimmten _Absicht_ dort stehen um etwas zu bewirken, also sollten sie ursprünglich eine Funktion haben.

Wenn diese Funktion, die damit _gemeint_ ist nur durch einen falschen Pfad "sabotiert" wurde macht es durchaus Sinn die ursprüngliche Absicht zu erfüllen und die _gemeinten_ (nicht die aktuell fehlenden) Dateien aufzurufen.

DomainSnake sollte wenn dann schon eine gründliche Fehlersuche durchführen und dabei auch die beabsichtigten Funktionen testen und erst dann entscheiden ob er sie braucht oder ob sie überflüssig sind.

Ich würde die Zeilen erst mal auskommentieren und evtl. später nochmal überprüfen wenn alles wieder etwas übersichtlicher geworden ist.

Ich entwickle meine Seiten grundsätzlich auf einem lokalen Server und schicke sie erst nach den Basis-Funktionstests online. Ich weiß warum

[socialexpert]

Hi,

ich muss es mal ausgraben, da ich eine wichtige Frage habe.

Der G Bot indexiert Seiten, die er laut meiner Robots.txt nicht soll..

Ich benötige eine Korrekte Ausführung für meine htaccess Datei.

Kann mir jemand aufschreiben, wie ich bestimmte Ordner schützen kann ?


Vielen Dank schon mal.