| |
 |
| Mozilla 1.2 beta mit Link-Prefetching |
|
|
Veröffentlicht durch XTaran am Donnerstag 17. Oktober, 15:17
Aus der Neue-Ideen,-neue-Standard-Verletzungen? Abteilung
|
|
|
|
|
Die Mozilla 1.2 Beta, die gerade rauskam, hat ein neues Feature: Link-Prefetching, was den Autoren von Webseiten ermöglicht, dem Browser zu sagen, er solle gleich folgende URLs in den Cache laden, weil der Benutzer sie sowieso gleich aufrufen wird.
|
|
|
|
|
|
|
Es gibt mehrere Varianten, das dem Browser beizubringen:
- Im HTML-HEAD:
<LINK REL="prefetch" HREF="/images/big.jpeg">
- Als HTTP-Header:
Link: </images/big.jpeg>; rel=prefetch
- Als HTTP-Header im Meta-Tag:
<META HTTP-EQUIV="Link" CONTENT="</images/big.jpeg>; rel=prefetch">
Aber sowohl die HTML-Variante als auch der HTTP-Header sehen mir sehr nach einer Verletzung des Standards HTML und des Praktisch-schon-Standards HTTP aus. Macht das Mozilla-Projekt jetzt einen auf Standard-Ignorieren wie Netscape zu Netscape-2.0/3.0-Zeiten? Zumindest kann ich nicht an einen Link-Header im Proposed-Standard HTTP/1.1 erinnern, noch an einen Wert 'prefetch' für den REL-Parameter zum LINK-Tag in HTML 4.01.
Wobei: Das Feature selbst ist ja schon recht nett, läßt sich aber IMHO auch potientiell für DoS-Attacken mißbrauchen. Und was diese Gefahr noch schlimmer macht: Vorerst kann man das Feature nur per Editieren von prefs.js und nicht per GUI deaktivieren.
Das Mozilla-Projekt schreibt dazu in der Link Prefetching FAQ:
We are considering adding UI for this preference; however, the overriding theory is that if link prefetching needs to be disabled then there must be something wrong with the implementation. We would rather improve the implementation if it does not work correctly, than simply expect users to locate some obscure preference in the preferences UI. Heck, the Mozilla preferences UI is already crowded enough ;-)
Die Begründung, daß nur eine fehlerhafte Implementation ein Absschalten gerechtfertigt, kann man genauso gut auf in HTML-Seiten eingebundene Bilder übertragen. Und schließlich kann man das Herunterladen und Anzeigen von Bildern schon lange und aus gut bekannten Gründen abschalten.
Hinweis gefunden bei Heise.
|
|
|
|
< Die automatische Zeitung | Druckausgabe | Internet-Zensur in Spanien immer heftiger > | |
|
|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
|
|
|
|
|
Mit diesem Feature müsste man sich komplett auf die sorgfalt der autoren der Seiten verlassen *schauder*. Wenn ich mir so ansehe, was da alles auf die armen Browser losgelassen wird, kann ich mir gut vorstellen, dass es Autoren geben wird, die beim Besuch ihrer Seiten das halbe Internet prefetchen lassen!
Lieber doch ned!
--
auch die Zehe ist ein Laufwerk
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Naja, immerhin werden dann vielleicht die Webmaster, die ein Hostingangebot mit Datenquota haben, ein bisschen vorsichtiger sein...
Gescheit gemacht könnte Symlink z.B. nen Link anbieten "Alle Stories von heute", wo der Mozilla dann mal prefetcht oder so... hmm... so sinnlos eigentlich. Wem fällt denn so nen Quatsch ein?
Ich hätte viel lieber mal das gute alte Roaming von Netscape 4 wieder als Feature im Mozilla. (Is worked on)
--
Den Symlink-Autoren bei der Arbeit zuhören? MP3 hier
|
|
|
|
|
|
|
|
|
|
|
|
|
100% Ack.
Was meiner Meinung nach sicherer (tm) wäre, wenn der Browser alle HTML-Seiten, die verlinkt sind, saugen würde. Naja, auch nicht gerade optimal, ich weiss. Oder, wenn wir schon das schöne Feature nutzen wollen, ginge es ja auch so, dass diese Prefetch-Liste vom Server mit Hilfe von Statistiken erstellt wird, und nicht vom Autor. Naja, auch nicht gerade was man sich wünscht.
Grundsätzlich sehe ich diesem "Feature" auch mit Skepsis entgegen, weil es a) Nicht Standard-Compliant (schreibt man das so?) und b) eine Reihe möglicher Exploits ermöglicht.
tL
tL
--
Keine Angst vor M$-Saftware! Ungeladen ist sie völlig harmos.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 17. October, 16:43 MEW (#4)
|
|
|
|
|
Ich finde dieses Prefetching besser als gar kein Prefetching.
Noch besser wäre es aber, wenn der Browser selbst (anstatt der Webseiten-Autor) entscheiden würde, welche Links er prefetcht. Ein Internet-Surfer kann aufgrund seiner Erfahrung auch abschätzen, welche Links er prefetchen könnte, also sollte das ein Browser auch bald schaffen können.
Man wird eher die Browser mit mehr "Intelligenz" ausstatten können, als dass man die Webautoren zu mehr Disziplin und oder Fairness erziehen könnte. Es wird immer Autoren und Seitenbetreiber geben, die solche Features missbrauchen (man denke an die anderen ehemals tollen Technologien wie Popups, Statuszeilen-Ändern, Dialogboxen anzeigen: Sie wurden alle missbraucht, heute sogar in der Mehrzahl der Fälle). Da überlässt man die Kontrolle besser dem Browser und dem Surfer.
|
|
|
|
|
|
|
|
|
|
|
|
|
Full ACK! Man bedenke, wie gut sich mit "Prefetch" Hits auf allerhand Websites erzeugen lassen, die sonst nie welche hätten... (pay-per-click Anbieter werden sich freuen - die blechen dann dafür, dass ihre Seiten pre-gefetcht wurden).
Grüsse vom Knochen
|
|
|
|
|
|
|
|
|
|
|
|
|
ich 'prefetche' selbst : )
dafür hat mozilla ja die tabs!
wenn ich einen symlink artikel lese, klicke ich die links mit der mittleren maustaste, damit sie in einem neuen tab im hintergrund geladen werden.
nachdem ich den artikel fertig gelesen habe, kann ich die anderen tabs lesen, welche sich mittlerweile im hintergrund geladen haben.
tabbed browsing ist einfach genial!
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
Schon mal was von
<link rel="stylesheet" type="text/css" href="my.css" />
gehört?
D'oh und das *hier*
--
mirabile, irc.ipv6.openprojects.net:6667 {#deutsch,#IceWM,#OpenBSD,#OpenBSD.de,#IPv6,#freenode.de,...}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja, klar, LINK als HTML-Tag gibt es, aber ob es REL="prefetch" als erlaubten Parameter dazu gibt, bezweifele ich momentan noch, das wäre mir sonst schonmal wo untergekommen. Bin aber auch zu faul zum Nachgucken. (Jedenfalls heute abend. :-)
--
Einer der Gnutella-Klone heißt Gnutoka, und ich frag mich, wann Gnusspli rauskommt...
|
|
|
|
|
|
|
|
|
|
|
|
|
Der HTML4-Standard erlaubt als Wert für das "rel"-Attribut alles, was sich das kranke Hirn eines Webautors ausdenken kann: Aus Absatz 6.12 "Link types": "Authors may wish to defined additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types." Im zweiten Beispiel für das Link-Element wird sogar eine ominöse "foo"-Beziehung eingeführt... (12.3.1)
|
|
|
|
|
|
|
|
|
|
|
|
|
Danke fuer's Nachgucken. Mussich damals, als ich mir das reingezogen hab, uebersehen haben. Oder einfach nur vergessen. :-)
--
Einer der Gnutella-Klone heißt Gnutoka, und ich frag mich, wann Gnusspli rauskommt...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 17. October, 23:11 MEW (#8)
|
|
|
|
|
ich weiss auch nicht wieso die Mozilla-Entwickler ein eigenes Attribut prefetch für das Link-Tag rel erfunden haben. Aber laut dieser link-prefetching-faq versteht mozilla ja auch rel="next". Ich zitiere mal aus http://www.w3.org/TR/REC-html40/types.html#type-links
[Link Types] Next:
Refers to the next document in a linear sequence of documents. User agents may choose to preload the "next" document, to reduce the perceived load time.
Also verhält sich hier Mozilla völlig standardkonform.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich denke, der Grund fuer das eigene Argument "prefetch" gegenueber der Nutzung von "next" beim Parameter REL ist folgender:
REL="next" ist wirklich dazu gedacht, eine Navigation aufzubauen, was z.B. bei Lynx ganz oben links auf jeder Seite erscheint und bei Galeon unter dem Links-Button. D.h. die Semantik ist vorerst mal "Das ist das naechste Dokument" und nicht "das sollst Du prefetchen", das ist nur eine moegliche Anwendung der Semantik.
Mit prefetch kannst Du
a) mehrere Dokumente prefetchen
b) z. B. auch schon das uebernaechste
c) Navigationsframes prefetchen, die nur auf der Startseite nicht erscheinen, auch wenn auf der Startseite schon Links zu allen Rubriken oder so gibt. (Hier gibt es kein "naechstes" Dokument.)
Beispiel: Eine Seite wie Slashdot oder Symlink hat auf der Hauptseite ein anderes Layout als auf den Seiten, auf denen die Artikel oder Kommentare stehen. Du kannst per prefetch die dort verwenden Bilder schonmal vorladen, mit "next" geht das nicht. (Vorladen? LOL!)
--
Einer der Gnutella-Klone heißt Gnutoka, und ich frag mich, wann Gnusspli rauskommt...
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 17. October, 23:44 MEW (#10)
|
|
|
|
|
Im Mozilla hätte ich gerne das Feature, dass er wie der Exploder die hintere Daumentaste meiner Maus als "Back" und die vordere als "Forward" interpretieren würde. Unter Linux und Windows. Damit surft man extrem schnell vor und rückwärts, und Preloading käme erst richtig in zur Geltung damit!
Hat der Mozilla das Feature vielleicht bereits und ich muss es nur noch richtig konfigurieren?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hi,
zumindest kann man das Mausrad in diese Richtung konfigurieren:
Edit/Preferences/Advanced/Mouse Wheel
Move Back and Forward
kiu
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 18. October, 14:55 MEW (#20)
|
|
|
|
|
Supertoll! Ich habe jetzt CTRL+Mausrad als History forward und back konfiguriert. Das Tolle dabei: Scrollen mit dem Mausrad (ohne CTRL) funktioniert trotzdem noch! :-)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sprich, er startet ganz kurz und verrauscht dann mit ner Fehlermeldung in der Konsole (gdkblarfdideldumm irgendwas) im Nirgendwo. Leider hab ich die Meldung nicht mehr präsent, da ich inzwischen nach 1.2a downgradet habe... Damit gehts vorerst mal.
--
Den Symlink-Autoren bei der Arbeit zuhören? MP3 hier
|
|
|
|
|
|
|
|
|
|
|
|
|
könnte dies auch klappen :) Bzw. wenn es Mozilla überhaupt zulässt.
Wenn man z.B. eintesllen kann das er nur links der gleichen Website nimmt, wäre das doch gut. Also nicht externe Links sondern interne :)
blackkoala
|
|
|
|
|
|
