nicht angemeldet
Durch einen Verweis mehrere Zielfenster ansprechen
Habe folgendes Ziel, möche durch das Klicke auf eine Link dass mehrere Zeiten in verschiedenen Frames geöffnet werden (Frames sind schon offen, als besser gesagt aktuallisiert). Hab mal gelesen dass dies über eine Java - Datei machen kann. wer kann mir helfen?
-
Habe folgendes Ziel, möche durch das Klicke auf eine Link dass mehrere Zeiten in verschiedenen Frames geöffnet werden (Frames sind schon offen, als besser gesagt aktuallisiert). Hab mal gelesen dass dies über eine Java - Datei machen kann. wer kann mir helfen?
Komisch, kam lange nicht mehr..
Java ist da fehl am Platze, aber Javascript hilft Dir weiter. Und die Seite mit den Fragen, die schon häufig gestellt wurden: http://forum.de.selfhtml.org/faq/#Q-32
Gruß,
soenk.e -
Habe folgendes Ziel, möche durch das Klicke auf eine Link dass mehrere Zeiten in verschiedenen Frames geöffnet werden (Frames sind schon offen, als besser gesagt aktuallisiert). Hab mal gelesen dass dies über eine Java - Datei machen kann. wer kann mir helfen?
Ich denke das kann dir helfen:
http://www.netzwelt.com/selfhtml/javascript/beispiele/zweiframes.htm
-
Moin!
Ich denke das kann dir helfen:
http://www.netzwelt.com/selfhtml/javascript/beispiele/zweiframes.htm
Wo kommen eigentlich immer noch diese Netzwelt-Links her. Nicht, dass ich was dagegen habe, wenn der Traffic ein wenig von teamone.de verlagert wird, aber selfhtml.teamone.de ist IMHO nun einmal die Zentrale mit dem neuesten Stand.
- Sven Rautenberg
-
Sorry, aber ich bekomme bei teamone immer nur kryptische zeichen in denen ich nichts erkennen kann, da muss man eben ausweichen
Gruß
Ingo
-
Sorry, aber ich bekomme bei teamone immer nur kryptische zeichen in denen ich nichts erkennen kann, da muss man eben ausweichen
Oh, das klingt nach Problemen mit komprimierten HTML-Seiten. Obwohl: Dann dürftest du dieses Forum eigentlich auch nicht sehen, denn das wird ebenfalls komprimiert ausgeliefert. Jedenfalls ist das durchaus ein beachtenswertes Vorkommnis.
Welchen Browser verwendest du?
- Sven Rautenberg
-
Sorry, aber ich bekomme bei teamone immer nur kryptische zeichen in denen ich nichts erkennen kann, da muss man eben ausweichen
Oh, das klingt nach Problemen mit komprimierten HTML-Seiten. Obwohl: Dann dürftest du dieses Forum eigentlich auch nicht sehen, denn das wird ebenfalls komprimiert ausgeliefert. Jedenfalls ist das durchaus ein beachtenswertes Vorkommnis.
Welchen Browser verwendest du?
- Sven Rautenberg
IE 6.0.2600.0000OC
screenshoot?, aber wie?
-
Moin!
IE 6.0.2600.0000OC
screenshoot?, aber wie?
Bringe den Bildschirm in einen Screenshotfähigen Zustand, drücke dann die Taste "Druck" oben rechts auf der Tastatur, öffne ein Bildbearbeitungsprogramm deiner Wahl (es geht auch MS Paint) und füge die Zwischenablage ein. Speichern.
Du brauchst dich aber nicht weiter zu bemühen, auch mein IE 6 hat bei selfhtml.teamone.de Probleme, will immer irgendeine Datei runterladen.
Ich werd's untersuchen und weitermelden. Sicherlich ist der IE6 schuld, denn der sollte doch genau wie sein Kollege IE5 komprimierte Seiten verstehen können, wenn er im HTTP-Header erlaubt, solche zu empfangen.
Andererseits kann es kein grundsätzliches Problem mit dem IE6 sein, denn laut http://webalizer.teamone.de/selfhtml/usage_200208.htm#TOPAGENTS waren im August 41% aller Browser auf SelfHTML ein IE6. Würde irgendwas nicht funktionieren, hätten sich sicher schon einige Leute deswegen gemeldet.
- Sven Rautenberg
-
Hallo,
zuhause bei mir der ie6 geht auch problemlos...
Odium
-
Moin!
zuhause bei mir der ie6 geht auch problemlos...
Es wird irgendein Servicepack nötig sein... die Knowledge-Base weiß sicher mehr. Bin nur gerade zu faul zum Suchen.
- Sven Rautenberg
-
Hallo
zuhause bei mir der ie6 geht auch problemlos...
Es wird irgendein Servicepack nötig sein... die Knowledge-Base weiß sicher mehr. Bin nur gerade zu faul zum Suchen.
nein, das ist ein Konfigurationsproblem des Proxis oder des Firewalls´in Verbindung mit dem IE. Die kryptischen Zeichen treten nicht auf allen Seiten auf, aber dafür im IE ab Version 5.
Auf Arbeit bin ich damit nämlich auch gestraft und verwende immer Netscape zum Zugriff auf SELFHTML. Das Forum selbst ist nicht von diesem Bug betroffen.Viele Grüße
Antje
-
Moin!
nein, das ist ein Konfigurationsproblem des Proxis oder des Firewalls´in Verbindung mit dem IE. Die kryptischen Zeichen treten nicht auf allen Seiten auf, aber dafür im IE ab Version 5.
Aha, das ist natürlich ein Indiz. So ein Proxy steht auch zwischen meinem IE 6 und dem Internet.
Allerdings: Opera, IE5, Mozilla etc. kommen prima mit dem gleichen Proxy zurecht. Also kann es so direkt am Proxy (Squid) nicht liegen, sondern eher doch am IE. Naja, ist ja auch kein Browser...
- Sven Rautenberg
-
Hallo Sven,
Aha, das ist natürlich ein Indiz. So ein Proxy steht auch zwischen
meinem IE 6 und dem Internet.
Allerdings: Opera, IE5, Mozilla etc. kommen prima mit dem gleichen
Proxy zurecht. Also kann es so direkt am Proxy (Squid) nicht liegen,
sondern eher doch am IE. Naja, ist ja auch kein Browser...das ist nicht der Punkt. Die Interpretation der Internet-Optionen
zwischen M$IE 5.0 und 5.5+ ist leider inkompatibel geändert worden ...Schalte mal im Mozilla in "prefs/all.js" den "Accept-Encoding:"-Header ab:
// Enable http compression: comment this out in case of problems with 1.1
pref("network.http.accept-encoding" ,"gzip, deflate, compress;q=0.9");und Du wirst dasselbe Verhalten erzielen wie beim M$IE.
Was die Browser nicht bestellt haben, das dekomprimieren sie nicht, selbst
wenn sie es könnten. Ausnahme: Opera 6 - der dekomprimiert immer.Viele Grüße
Michael-
Moin, Michael!
Erstens: Ich wußte, dass du dich noch melden würdest - als Experte für Kompression. :)
Schalte mal im Mozilla in "prefs/all.js" den "Accept-Encoding:"-Header ab:
// Enable http compression: comment this out in case of problems with 1.1
pref("network.http.accept-encoding" ,"gzip, deflate, compress;q=0.9");und Du wirst dasselbe Verhalten erzielen wie beim M$IE.
Was die Browser nicht bestellt haben, das dekomprimieren sie nicht, selbst
wenn sie es könnten. Ausnahme: Opera 6 - der dekomprimiert immer.Ist das aber nicht idiotisch? Der Server liefert die Ressource mit entsprechenden HTTP-Headern aus, in denen steht, dass der Inhalt mit gzip komprimiert ist ("Content-Encoding: gzip"). Der Mime-Typ stimmt auch ("Content-Type: text/html"). Es gibt also absolut keinen Hinderungsgrund für den Browser, diese Angaben nicht zu verstehen (dazu in der Lage ist er ja) - es sei denn, der Proxy unterschlägt plötzlich diese Angaben. Dein HTTP-Trace läuft leider außerhalb meines Netzwerkes, deshalb kann ich das nicht "mal eben" kontrollieren. Hast du Info, wie Squid sich verhält?
Mein IE6 kann nach Korrektur der Proxy-Einstellungen (HTTP/1.1 für Proxy verwenden) jedenfalls jetzt prima komprimierte Dokumente abrufen. :)
- Sven Rautenberg
-
Hallo Sven,
Was die Browser nicht bestellt haben, das dekomprimieren sie nicht,
selbst wenn sie es könnten. Ausnahme: Opera 6 - der dekomprimiert
immer.
Ist das aber nicht idiotisch?Doch, ist es. ;-)
(http://www.schroepl.net/projekte/mod_gzip/browser.htm)Der Server liefert die Ressource mit entsprechenden HTTP-Headern
aus, in denen steht, dass der Inhalt mit gzip komprimiert ist
("Content-Encoding: gzip"). Der Mime-Typ stimmt auch ("Content-Type:
text/html"). Es gibt also absolut keinen Hinderungsgrund für den
Browser, diese Angaben nicht zu verstehen (dazu in der Lage ist
er ja) - es sei denn, der Proxy unterschlägt plötzlich diese Angaben.Das tut er sicher nicht. Er fügt allerdings eigene HTTP-Header hinzu
("Via:" ist einer davon), und man kann ihn so konfigurieren, daß er
Header herausfiltert.Einer unserer Kunden hat einen Squid, der den HTTP-Header "Accept-
Encoding" herausnimmt! Offenbar will der auf Teufel komm raus cachen
und hat schlechte Erfahrungen mit komprimierten Daten ... was ich
natürlich häßlich finde, weil _mein_ mod_gzip brav ein "Vary:" sendet.
(Schon vor meinem Patch - die mod_headers-Lösung habe ich schon ein
paar Monate im Einsatz.)Dein HTTP-Trace läuft leider außerhalb meines Netzwerkes, deshalb
kann ich das nicht "mal eben" kontrollieren.Willst Du eine Kopie haben für eine lokale Installation?
Hast du Info, wie Squid sich verhält?
Ich wiederum habe keinen Squid zur Hand ... aber ich gehe davon aus,
daß Squid da nichts falsch macht.Mein IE6 kann nach Korrektur der Proxy-Einstellungen (HTTP/1.1 für
Proxy verwenden) jedenfalls jetzt prima komprimierte Dokumente
abrufen. :)Was im Prinzip beweist, daß Squid den "Content-Encoding"-Header sendet.
Viele Grüße
Michael-
Moin, Michael!
Ist das aber nicht idiotisch?
Doch, ist es. ;-)
(http://www.schroepl.net/projekte/mod_gzip/browser.htm)Oha, die "Liste des Horrors". :)
Dein HTTP-Trace läuft leider außerhalb meines Netzwerkes, deshalb
kann ich das nicht "mal eben" kontrollieren.Willst Du eine Kopie haben für eine lokale Installation?
Sehr gerne. Mailadresse ist oben. :)
- Sven Rautenberg
-
-
-
-
-
Hallo Antje,
nein, das ist ein Konfigurationsproblem des Proxis oder des Firewalls´
in Verbindung mit dem IE. Die kryptischen Zeichen treten nicht auf
allen Seiten auf, aber dafür im IE ab Version 5.mein M$IE 4.0 im "compatibility mode" kann das auch schon (einen "echten"
habe ich nicht mehr zum Probieren).Auf Arbeit bin ich damit nämlich auch gestraft
</?m=125066&t=22445> sollte Abhilfe schaffen können.
und verwende immer Netscape zum Zugriff auf SELFHTML. Das Forum selbst
ist nicht von diesem Bug betroffen.Vermutlich hält der Caching Proxy dazwischen URLs mit Query-Strings nicht
für "langlebig" und cached sie deshalb nicht ...Die HTTP-Header aller Virtual Hosts des Self-Portals sind jedenfalls in
dieser Hinsicht nicht unterschiedlich.Viele Grüße
Michael
-
-
-
-
HI Sven,
Andererseits kann es kein grundsätzliches Problem mit dem IE6 sein,
denn laut http://webalizer.teamone.de/selfhtml/usage_200208.htm#TOPAGENTS
waren im August 41% aller Browser auf SelfHTML ein IE6. Würde irgendwas
nicht funktionieren, hätten sich sicher schon einige Leute deswegen
gemeldet.soweit ich weiß, ist die entsprechende Konfiguration (siehe
</?m=125066&t=22445>) leider _nicht_ der Installations-Default
des M$IE. Allerdings ist in der Tat ein Caching Proxy notwendig, um
das Problem auszulösen.Viele Grüße
Michael -
Hallo Sven
Du brauchst dich aber nicht weiter zu bemühen, auch mein IE 6 hat bei selfhtml.teamone.de Probleme, will immer irgendeine Datei runterladen.
Das Problem habe ich mit dem IE6 auch ständig, davon betroffen sind aber nur Seiten die nicht den Content-Type text/html (z.B. text/plain) senden.
Leider habe ich die Ursache, bzw. eine passende Lösung bis jetzt noch nicht gefunden.
Grüsse
Eisbär
-
-
Hi,
Sorry, aber ich bekomme bei teamone immer nur kryptische zeichen
in denen ich nichts erkennen kann, da muss man eben ausweichen
Welchen Browser verwendest du?
IE 6.0.2600.0000OC"Extras" -> "Internet-Optionen" -> "Erweitert" -> runter scrollen bis
"Einstellungen für HTTP/1.1" und dann[x] HTTP/1.1 über Proxyverbinderungen verwenden
[x] HTTP/1.1 verwendenBei M$IE 5.5 und 6.0 müssen _beide_ Boxen markiert sein - bei M$IE 5.0
reicht die zweite. (Das weiß ich leider auch erst seit ein paar Tagen,
die Doku auf meiner Homepage ist bisher nur für M$IE 5.0 richtig ...)M$IE beenden und neu starten - danach sollte es gehen.
Kontrolle: Einen Request an
http://www.schroepl.net/cgi-bin/http_trace.pl
senden und nachsehen, welcher "Accept-Encoding:"-Header gesendet wird.Viele Grüße
Michael
-
-
Hi Ingo,
Sorry, aber ich bekomme bei teamone immer nur kryptische zeichen
in denen ich nichts erkennen kann, da muss man eben ausweichenverwendest Du (implizit oder explizit) einen Caching Proxy?
Teamone verwendet eine (die einzige bisher verfügbare) mod_gzip-Version,
welche zwar komprimiert und dabei implizit Content Negotiation betreibt
(nämlich über den HTTP-Header "Accept-Encoding"), aber diese Information
_nicht_ an Proxy-Server ausliefert (in Form eines "Vary:"-Headers).Der Vary-Header würde den Proxy warnen: "Achtung, diese Daten hier sind
das Ergebnis einer Verhandlung - gib sie nur dann an Browser weiter,
wenn Du sicher sein kannst, daß diese Browser die Daten auch verstehen
werden."
Letzteres herauszufinden ist nicht ganz einfach - der Proxy müßte nämlich
im Wesentlichen die auf dem Server statt gefundene Negotiation selbst
ebenfalls durchführen, und dazu natürlich begriffen haben, wovon der
Server die Auslieferung des entsprechenden Content abhängig gemacht hat.
Genau für letzteres ist der Vary:-Header notwendig.Meines Wissens kann das _kein_ existierender Proxy-Server. Der verbrei-
tete Proxy-Server Squid (mit dessen Entwicklern ich gerade über genau
dieses Thema diskutiere ...) erkennt aber immerhin am Auftreten eines
"Vary:"- Headers, daß er vorsichtig sein sollte - und schaltet in diesem
Falle unabhängig von anderen HTTP-Headern das Caching für diesen Content
ab (seit Squid 2.0, also schon seeehr lange). Nur müßte mod_gzip ihm
dazu natürlich überhaupt erst mal einen Vary:-Header senden ...In diesem Vary:-Header müßte dann die Liste derjenigen HTTP-Header auf-
geführt sein, welche der Server für seine Entscheidung ausgewertet hat.
In dem Moment, in dem der Proxy sich für das Speichern eines Inhalt in
seinem Cache entscheidet, weiß er noch, welche HTTP-Header bei derjenigen
Anfrage geliefert wurden, die zu diesem Ergebnis geführt haben; trifft
ein nachfolgender Request mit exakt denselben Werten in allen genannten
HTTP-Headern ein, dann darf er das Ergebnis ausliefern - denn dann würde
die erneute Verhandlung auf dem Server sicher zum selben Ergebnis führen.Genau diese Denkweise, also das parallele Vorrätighalten verschiedener
Verhandlungsergebnisse (Encodings sind nur _eine_ Art des Problems -
Language Negotiation ist eine weitere), wird gerade in Squid 2.5 ein-
gebaut, der also in absehbarer Zeit das Caching von verhandelten In-
halten unterstützen wird. (Deshalb gehen die Squid-Leute gerade "mit
dem Hut herum" und reden mit ihren potentiellen "Verhandlungspartnern".)Welche HTTP-Header mod_gzip nun genau mitliefern müßte, das hängt von
der verwendeten mod_gzip-Konfiguration ab.
Im einfachsten Falle würde ein "Vary: Accept-Encoding" ausreichen.
Hat der Server aber von der Konfigurationsregen "mod_gzip_item_**clude
reqheader" Gebrauch gemacht, um Regeln von speziellen HTTP-Headern
abhängig zu machen, dann müßte mod_gzip mitschreiben, welche dieser
Regeln auf dem Weg zu einer Entscheidung geprüft wurden und den Vary:-
Header entsprechend dynamisch erzeugen.
Ganz schlecht sind in diesem Falle natürlich Regeln, welche über den
"User-Agent:" gehen - weil dies den Proxy dazu zwingen würde, viele
tausend Einträge zu speichern, nämlich für jeden User-Agent einen ...Eine mod_gzip-Version mit einem trivialen Patch, um einfach nur "Vary:
Accept-Encoding" mit jedem komprimiert ausgelieferten Inhalt zu senden,
gibt es auf meiner Homepage
(http://www.schroepl.net/projekte/mod_gzip/links.htm)
zum Download. Ersatzweise kann man das Problem auch durch den Einsatz
von mod_headers umgehen.Eine Version, welche den Vary-Header dynamisch baut, kriege ich mit
meinen bescheidenen Kenntnissen über C und vor allem über das Innenleben
des Apache im Moment nicht hin. (Der Trick könnte u. a. darin bestehen,
möglichst schon beim Apache-Start zu berechnen, welche Vary:-Felder
gesendet werden müssen, nicht erst beim jeweiligen Request - denn _was_
geprüft werden muß, hängt nur von der Konfiguration ab, nicht vom der
eigentlichen Anforderung.)
In jedem Falle müßte das Regelauswertungsverfahren in mod_gzip umge-
schrieben werden, weil es nun die "kritischen" Regeln vor den "unkri-
tischen" prüfen muß und nicht einfach abbrechen darf, wenn es zu einem
Entschluß gekommen ist - weil es die Begründung für diesen Beschluß dem
Anrufer mitteilen muß.Um HTTP/1.1 _vollständig_ zu unterstützen, müßten sowohl mod_gzip als
auch Squid noch eine ganze Menge mehr tun - herauszufinden, was genau
(und ob das algorithmisch überhaupt lösbar ist), findet gerade auf der
mod_gzip-Mailingliste statt ...Viele Grüße
Michael
-
-
-