jetzt habe ich es nach 5 durchgelesenen threads auch geschafft - ein link in einen thread in dem tatsächlich etwas gelöst wurde wäre vielleicht sinnvoller gewesen? =)
Hilfe zur Selbsthilfe lautet das Credo. Offensichtlich hat es in dem Fall auch funktioniert.
Können die das nicht global in der DB rausparsen? Die Abschnitte sind doch entsprechend gekennzeichnet.
also quasi den code vom Stylish Template ins Bookmarklet einbasteln und es irgendwie hinbekommen das das Bookmarklet automatisch bei jeder Seite läd?
Das lässt sich mit Erweiterungen wie Greasemonkey, Ubiquity oder JetPack realisieren. Auf Grund der hier spezifizierten Anforderungen würde ich diese auch in der Reihenfolge empfehlen.
Teste es im Safe-Mode und mit einem neuen Profil.
Man kann auch solche Binsenweisheiten nicht oft genug wiederholen, leider ist die Anzahl derer noch immer zu niedrig, die sich an solche einfachen Regeln halten.
Teste es im abgesicherten Modus deines Betriebssystems.
Erstellt, Browserspielseite geöffnet, Seite mit Timer aufgerufen, Seite aktualisiert... selbes Prob.
Dann hast du also nicht wirklich geprüft, ob keine Erweiterung vorhanden ist. :roll:
Zitat von pardauzaber vielleicht magst du es ja trotzdem erklären: Timestamp bedeutet
http://de.wikipedia.org/wiki/Unixzeit
max-age gibt laut RFC ein Intervall an und keinen Zeitpunkt wie bspw. der Expires-Header. Der Server macht es bei n-tv korrekt, dort gibt er 120 Sekunden für max-age an. Der mtb-Server hingegen nimmt die aktuelle UNIX-Zeit (ist nebenbei identisch mit der Expires-Angabe) und setzt diese für den max-age-Header. Das ist zwar formal zulässig, aber semantisch Blödsinn.
Und der Server sagt meinem FX, wann er wieder einen Abruf machen soll, in diesem Fall nach 39 Jahren?
Er teilt ihm mit, ab welchem Zeitpunkt sich eine Nachfrage wieder lohnt, ja. Leider mit der recht idiotischen Zeitvorgabe.
Aber mit dem entsprechend gesetzten browser.bookmarks.livemark_refresh_seconds würde man dem ja entgegenwirken.
Nein, wenn ein Server dem Fx sagt, dass es sich erst wieder nach 39 Jahren lohnt die Inhalte neu anzufordern, warum soll der Fx das nicht einbeziehen? Natürlich ist das in dem Fall Quatsch, aber denk mal an Feeds von Blogs, die bspw. nur alle zwei Tage aktualisiert werden. Da könnte der Server mitteilen, dass sich eine Aktualisierung nur alle 24 Stunden lohnt. Jetzt soll der Fx also diese freundliche Angabe ignorieren und trotzdem alle 60 Minuten (oder wie auch immer der Wert gesetzt ist) nachfragen? Das ist verschwendete Bandbreite und belastet den Server unnötig. Auch wenn man den Datentransfer als vernachlässigbar deklariert, es ist auf die implementiere Weise trotzdem effizienter.
Damit ist auch die Frage von TheRave beantwortet.
Was bedeutet "Cache-Control max-age" genau?
Das steht ausführlich oben in dem verlinkten RFC, sollte sich aber auch aus dem Zusammenhang ergeben.
(Chronik / Besuchte Seiten), die mit der Funktion an sich eigentlich gar keine Verbindung haben sollte
Das kann man auch anders sehen und dann ist der Zusammenhang auch deutlich :wink:
Heißt das, wenn Online bei Ebay nur noch "http" erscheint und das Schloßsymbol weg ist, kann jeder Außenstehende z.B. die persönlichen Daten einsehen?!
Nicht jeder. Aber theoretisch jeder der die Kommunikation zwischen den eBay-Servern und deinem Rechner mitlesen kann. Das betrifft aber grundsätzlich jeglichen HTTP-Verkehr, den du nicht durch weitere Maßnahmen absicherst. Ist also nicht ungewöhnlich oder überraschend.
Ändere dein Passwort einem mit einem neuen Profil.
Die Serverkonfiguration kannst du nicht "auslesen", allerdings kannst du dir die Response-Header des Servers im HTTP-Dialog ansehen und dort sind solche Angaben vermerkt. Dazu kannst du bspw. Programme wie wireshark verwenden.
Dass es mit dem 2er funktioniert hat, bedeutet nicht, dass der Server hier keinen Fehler macht. Der Fehler ist unbestritten. Es mag aber sein, dass der Fx im 2er bei den Feeds die Caching-Angaben in den Headern ignoriert hat. Im Rahmen der kontinuierlichen Weiterentwicklung wurde der Fx dort dann wohl verbessert, mit dem nachteiligen Effekt, dass solche Schlampereien nun auffallen. Ich habe allerdings keine Lust den Quellcode oder die Bugreports diesbezüglich zu untersuchen.
Es spielt auch keine Rolle ob Mozilla das technisch am konkreten Rechner bestimmen kann. Das Wissen über diesen prinzipiellen Umstand ist vorhanden, daher wäre es geboten für Home-User die Möglichkeit zu schaffen diese Prüfung und Benachrichtigung optional anzubieten. Ein einfach Switch über about:config sowie ein paar wenige Zeilen Code und dieser Makel wäre behoben. Warum das seit Jahren konsequent ignoriert wird erschließt sich mir nicht. Für mich ist das peinlich bis beschämend, allerdings weiß ich persönlich mir selbst zu helfen.
Ich kann es zwar mit dem Testcase dort nicht reproduzieren, bis zum Release von Fx 3.6 kann es allerdings noch eine Weile (Monate) dauern.
Bzgl. des neuen Fx-Profils, war das auch jungfräulich als du das getestet hast? So gänzlich ohne irgendwelche Erweiterungen?
Dann sollte man dem Sohn eben kein Admin-Konto zur Verfügung stellen solange er damit nicht verantwortungsvoll umgehen kann und will. :wink:
Ansonsten ist mir noch immer nicht ganz klar, in welchem Zustand sich das System nun gegenwärtig befindet. Nach einer erneuten Infektion sollte es stets komplett bereinigt werden. Erst dann macht es einen Sinn über negative Effekte mit verschiedenen Programmen zu diskutieren.
Und du hast tatsächlich den Shockwave-Player installiert? Nicht Shockwave Flash? Ich frage nur zur Sicherheit.
Teste es im Safe-Mode und mit einem neuen Profil.
Mit Opera auch so? Dann solltest du dich vielleicht an Adobe wenden.
