nicht angemeldet
(Java / JavaScript) Netscape 4: URL 'assign.class'
Liebe Forum-Leser,
schon in </archiv/1999_1/t02513.htm#a11804> hat Cheatah festgestellt,
daß in seinem Server-Log eine Reihe von Zugriffen auf URLs der Form
"xxx/java/assign.class" auftauchen, die er sich nicht erklären konnte
(und die jeweils mit Status 404 abgelehnt wurden).
Etwas Ähnliches haben wir nun heute ebenfalls festgestellt.
Bei uns lauten die URLs "/netscape/assign.class" und führen ebenfalls
ins Leere.
Java-Anwendungen gibt es auf unserem gesamten Server keine.
In den damaligen Threads (in </archiv/2000_3/t16406.htm#a82783>
gab es nochmal so eine Diskussion) wurde vermutet, es könnte sich um
ein undokumentiertes Netscape-Feature handeln, vergleichbar zu M$s
favicon.
Genaueres wurde allerdings in keinem dieser Threads festgestellt.
Google kann leider nicht (in einer mir bekannten Bedienungsform) nach
Zeichenketten suchen, die einen '.' enthalten - das ist für ihn ein
Nicht-Zeichen, welches er als Wildcard interpretiert. Deshalb liefert
Google bei der Suche nach dieser Zeichenkette Unmengen 'falscher'
Treffer, aber auch Unmengen von Treffern in irgendwelchen Server-
Statistiken. Und einen einzigen Treffer im Self-Archiv, nämlich
Cheatahs Posting.
Auch eine Suche bei Mozilla oder Netscape hat mich nicht weiter gebracht.
Beim Versuch, der Sache nachzugehen, haben wir mal sämtliche Zugriffe
einer IP-Adresse aus dem access_log gefiltert (das war ein Zugriff von
einem unserer eigenen Arbeitsplätze, insbesondere keine obskuren Book-
marks irgendwelcher Besucher, sondern eine nachvollziehbare Session)
und die direkte Umgebung des entsprechenden Zugriffs analysiert.
Dabei haben wir für diese "assign.class"-Referenz ein paar Besonder-
heiten festgestellt:
a) Keiner dieser Zugriffe enthält einen Referrer.
(Ich hatte natürlich gehofft, damit die Seite identifizieren zu
können, welche diesen Zugriff auslöst - leider nein.)
b) Die verwendeten Browser sind irgendwelche Netscape-4-Versionen.
(4.51, 4.61, diverse 4.7x wurden beobachtet.)
c) Aufgrund des jeweiligen 'Surf-Weges' der IP-Adresse habe ich Grund
zur Annahme, daß in diesem Moment ein JavaScript-"document.write"
erstmalig in dieser Browser-Sitzung ausgeführt worden ist.
Ich habe irgendwie in Erinnerung, daß bei Netscape 4 die JavaScript-
und die Java-Engine aneinander gekoppelt sind, d. h. daß in dem Moment,
in welchem erstmalig JavaScript-Befehle ausgeführt werden, auch die
Java-VM geladen wird oder so ähnlich.
Und wenn dies der Fall wäre, dann könnte dieser seltsame Zugriff ein
Versuch sein, irgendwelche Zusatzinformationen bei der Initgialisierung
der Java-VM aufzusaugen - nicht, daß ich mir vorstellen könnte, wozu
das im Einzelnen gut sein sollte.
Soweit also die (für mich reichlich verwirrenden) Beobachtungen.
Nun meine Frage:
1. Hat irgendjemand weiterführende Informationen zu diesem Themenkreis
und kann womöglich erklären, was da los ist?
2. Kann man diesen Zugriff irgendwie client-seitig unterbinden?
3. Macht es Sinn, den Zugriff per URL-rewriting irgendwohin zu lenken
(ich möchte gerne ein 'sauberes' error_log haben) - und wenn ja,
welche Eigenschaften müßte der Content des Ziel-URLs aufweisen,
damit der Netscape-Browser dabei nicht abstürzt etc.?
Viele Grüße
Michael
-
Hallo Michael
"xxx/java/assign.class" auftauchen, die er sich nicht erklären konnte
(und die jeweils mit Status 404 abgelehnt wurden).Etwas Ähnliches haben wir nun heute ebenfalls festgestellt.
Bei uns lauten die URLs "/netscape/assign.class" und führen ebenfalls
ins Leere.
Java-Anwendungen gibt es auf unserem gesamten Server keine.Dabei haben wir für diese "assign.class"-Referenz ein paar Besonder-
heiten festgestellt:b) Die verwendeten Browser sind irgendwelche Netscape-4-Versionen.
(4.51, 4.61, diverse 4.7x wurden beobachtet.)c) Aufgrund des jeweiligen 'Surf-Weges' der IP-Adresse habe ich Grund
zur Annahme, daß in diesem Moment ein JavaScript-"document.write"
erstmalig in dieser Browser-Sitzung ausgeführt worden ist.Netscape speichert seine Java-Files in einem Unterverzeichnis. So wie es ausschaut, könnte irgendeine Javaklasse falsch referenziert sein.
Ich habe irgendwie in Erinnerung, daß bei Netscape 4 die JavaScript-
und die Java-Engine aneinander gekoppelt sind, d. h. daß in dem Moment,
in welchem erstmalig JavaScript-Befehle ausgeführt werden, auch die
Java-VM geladen wird oder so ähnlich.Nicht immer. Meist tritt der Fall ein, wenn man Eigenschaften des screen-Objektes abfragt bzw. liveConnect verwendet.
Allerdings ist bekannt, dass Netscape 4 in Verbindung mit document.write einige Bugs hat.
Es könnte durchaus sein das sich hier zwei Bugs gesucht und gefunden haben und dadurch zu diesen seltsamen Ergebnis führen. Eventuell wird auch noch css verwendet, was das Problem sozusagen komplettiert.Soweit also die (für mich reichlich verwirrenden) Beobachtungen.
- Kann man diesen Zugriff irgendwie client-seitig unterbinden?
ich fürchte nein, abgesehen von einem Wechsel des Browsers, eventuell hilft auch eine Neuinstallation. Alternativ eine großangelegte Testreihe, wo man versucht die Ursachen zu finden.
Allerdings wäre es vielleicht nützlich, wenn ihr mal eine Umfrage macht, ob Probleme auftreten. Es scheint sich jedoch kaum jemand zu beschweren, also scheinen die Betroffenen es gar nicht zu merken.
- Macht es Sinn, den Zugriff per URL-rewriting irgendwohin zu lenken
Nein. Es sei denn, du bietest die Javaklasse an :-)
Ich schätze eher, dass Fehlen der Klasse wird behandelt und stört den Nutzer nicht.(ich möchte gerne ein 'sauberes' error_log haben) - und wenn ja,
welche Eigenschaften müßte der Content des Ziel-URLs aufweisen,
damit der Netscape-Browser dabei nicht abstürzt etc.?hm, lege doch eine leere Datei unter diesen Namen ab. Wenn keine Beschwerden kommen störts niemanden und wenn doch, dann kennt ihr den/die Übeltäter und könnt zielgerichtet Ursachenforschung betreiben.
Mehr kann ich leider auch nicht dazu sagen.
Viele liebe Grüße
Antje
PS: Schön, dass du wieder dabei bist.
-
Hi Antje,
Java-Anwendungen gibt es auf unserem gesamten Server keine.
diese Aussage stand am Anfang meines Postings - und sie macht es mir so
schwer, die Ursache des Problems zu verstehen.Ich weiß sehr genau, was auf unserem Server drauf ist - ich baue ihn ja
selber, ich mache die Webalizer-Auswertungen ... Kein Java. Bestimmt nicht.Netscape speichert seine Java-Files in einem Unterverzeichnis.
So wie es ausschaut, könnte irgendeine Javaklasse falsch referenziert
sein.Aber von wem? Wie oben erwähnt ...
Ich habe irgendwie in Erinnerung, daß bei Netscape 4 die JavaScript-
und die Java-Engine aneinander gekoppelt sind, d. h. daß in dem Moment,
in welchem erstmalig JavaScript-Befehle ausgeführt werden, auch die
Java-VM geladen wird oder so ähnlich.
Nicht immer. Meist tritt der Fall ein, wenn man Eigenschaften des
screen-Objektes abfragt bzw. liveConnect verwendet.Ersteres tun wir an dieser Stelle möglicherweise wirklich (muß ich mal
meinem Kollegen erzählen. "liveConnect" sagt mir gar nichts.
Wir machen durchaus DHTML, aber sonst nichts Exotisches.Soweit also die (für mich reichlich verwirrenden) Beobachtungen.
2. Kann man diesen Zugriff irgendwie client-seitig unterbinden?
ich fürchte nein, abgesehen von einem Wechsel des Browsers,
eventuell hilft auch eine Neuinstallation. Alternativ eine
großangelegte Testreihe, wo man versucht die Ursachen zu finden.
Allerdings wäre es vielleicht nützlich, wenn ihr mal eine Umfrage
macht, ob Probleme auftreten.Anscheinend nicht. Es waren bisher 6 Zugriffe am ersten Produktionstag
-
- [30/Jan/2002:09:35:34 +0100] "GET /netscape/assign.class HTTP/1.0" 404 3692 "-" "Mozilla/4.61 [de] (OS/2; U)"
-
- [30/Jan/2002:10:27:54 +0100] "GET /netscape/assign.class HTTP/1.0" 404 3692 "-" "Mozilla/4.75 [de]C-CCK-MCD QXW0324v (WinNT; U)"
-
- [30/Jan/2002:11:15:17 +0100] "GET /netscape/assign.class HTTP/1.0" 404 3692 "-" "Mozilla/4.77 [en] (WinNT; U)"
-
- [30/Jan/2002:12:00:50 +0100] "GET /netscape/assign.class HTTP/1.0" 404 3692 "-" "Mozilla/4.61 [de] (OS/2; U)"
-
- [30/Jan/2002:13:37:43 +0100] "GET /netscape/assign.class HTTP/1.0" 404 3692 "-" "Mozilla/4.51 [de]C-CCK-MCD QXW03200 (WinNT; I)"
-
- [30/Jan/2002:15:10:35 +0100] "GET /netscape/assign.class HTTP/1.0" 404 3692 "-" "Mozilla/4.61 [de] (OS/2; U)"
und darunter eben einer (NC4.77) von dem Kollegen, der die Seite selbst
baut, in der besagter document.write-Aufruf drin steht.
Der hat auch erst durch unser access_log gemerkt, daß er diesen Zugriff
ausgelöst hat.Es scheint sich jedoch kaum jemand zu beschweren, also scheinen die
Betroffenen es gar nicht zu merken.So sieht's aus ... Mirakel, Mirakel.
- Macht es Sinn, den Zugriff per URL-rewriting irgendwohin zu
lenken
Nein. Es sei denn, du bietest die Javaklasse an :-)
Ein rewrite würde wenigstens mein "heiliges" error_log nicht "beflecken" ...
Ich schätze eher, dass Fehlen der Klasse wird behandelt und stört
den Nutzer nicht.Behandelt von wem? Es gibt keine Java-Anwendungen auf der Maschine.
(ich möchte gerne ein 'sauberes' error_log haben) - und wenn ja,
welche Eigenschaften müßte der Content des Ziel-URLs aufweisen,
damit der Netscape-Browser dabei nicht abstürzt etc.?
hm, lege doch eine leere Datei unter diesen Namen ab. Wenn keine
Beschwerden kommen störts niemanden und wenn doch, dann kennt ihr
den/die Übeltäter und könnt zielgerichtet Ursachenforschung betreiben.Tja, wenn ich den Zugriff sinnvoll reproduzieren könnte - aber die Stelle,
wo das passiert, ist praktisch die Einstiegsseite unserer Anwendung.
Da kommen hunderte von Besuchern ständig vorbei, und es passiert nur
ab und zu.Viele Grüße
Michael-
... Nachtrag:
-
- [30/Jan/2002:09:35:34 +0100] "GET /netscape/assign.class HTTP/1.0" 404 3692 "-" "Mozilla/4.61 [de] (OS/2; U)"
die sechs genannten Zeilen waren das _vollständige_ Ergebnis eines
"grep class access_log"
(nur um meine Aussage "kein Java" zu verdeutlichen ;-).
Das Zeug scheint mir mehr und mehr nach irgend einem JavaScript-
Seiteneffekt zu riechen:- Auf dem Entwicklungs-Server unserer Anwendung habe ich auch welche
gefunden (etwa alle paar Tage einen, und genau von den beiden PCs
derjenigen Leute, welche das DHTML-Zeug entwickeln bzw. testen),
während - auf dem daneben stehenden Server, welcher als Dokumentations- und
Download-Maschine wesentlich mehr Zugriffe hat, aber eben keine DHTML-
Anwendungen, in den letzten zwei Monaten nicht ein einziger solcher
Zugriff zu verzeichnen ist.
Und es sind dieselben Clients (Maschinen und Browser), welche auf beide
Server zugreifen - unsere Abteilung eben.
An den PCs bzw. Netscape-Installationen liegt es also wohl eher nicht ...Viele Grüße
Michael -
-