nicht angemeldet
auto refresh on page load
Moin, Leute!
Meine Schule hat nen ziemlich dominanten proxy-server. Folgendes ist mein Problem: Es geht um ein php-basiertes Internetspiel (www.imperialconflict.com). Wenn ich dort eine Seite öffne, öffnet der Browser nicht etwa die aktuelle Seite vom Server, sondern die Seite, die von Tagen vorher noch aufm proxy gespeichter ist. Also mache ich mir meine eigene Linkleiste. Wie kann ich in einem Link definieren, dass der Browser den Proxy umgeht und direkt vom Internetserver lädt??
wäre durchaus interessant. danke im voraus, Karsten
P.S.: Hat irgendjemand eine Idee, wie ich die PHPSessionID aus der Seite im Subframe übernehme und an die URL des Linkframes ranhänge?
-
Hi,
Wie kann ich in einem Link definieren, dass der Browser den Proxy umgeht und direkt vom Internetserver lädt??
in einem Link geht das nicht. Die Seite muss entsprechende Caching-Informationen beinhalten, oder der Proxy muss feiner konfiguriert werden.
Wenn Du übrigens bei gehaltener Shift-Taste einen Reload der Seite ausführst, schickt der Browser dem Proxy die Information mit, dass dieser seine Daten aktualisieren muss. Das geht aber erst _nach_ dem Linkklick.
P.S.: Hat irgendjemand eine Idee, wie ich die PHPSessionID aus der Seite im Subframe übernehme und an die URL des Linkframes ranhänge?
Mit einer Programmiersprache. Wenn es um Frames geht, scheiden serverseitige Mechanismen leider weitgehend aus, also müsstest Du Dich von JavaScript o.ä. abhängig machen. Probleme bekommst Du dann spätestens, wenn die einzelnen Frames von unterschiedlichen Hosts geladen werden, was mir hier der Fall zu sein scheint.
Cheatah
-
Hi,
Meine Schule hat nen ziemlich dominanten proxy-server.
... Du meinst, einen ziemlich "kooperativen" ... ?
Denn tendentiell ist die Idee, in einem Proxy zu cachen, ja eine Verbesserung der Situation - sofern alle Beteiligten (vor allem der Produzent der Inhalte, also Du!) sich an die Spielregeln von HTTP halten.
Folgendes ist mein Problem: Es geht um ein php-basiertes Internetspiel
(www.imperialconflict.com). Wenn ich dort eine Seite öffne, öffnet der
Browser nicht etwa die aktuelle Seite vom Server, sondern die Seite,
die von Tagen vorher noch aufm proxy gespeichter ist.Das bedeutet, daß entweder der HTTP-Server dem Proxy nicht hinreichend genau beschrieben hat, was dieser darf und was nicht, oder daß der Proxy sich über die entsprechenden "Befehle" (HTTP-Header) hinweg setzt, also das HTTP-Protokoll nicht korrekt beachtet. Alternative 1 ist natürlich die _wesentlich_ wahrscheinlichere - deshalb würde ich an dieser Stelle mit der Suche beginnen.
Also mache ich mir meine eigene Linkleiste.
Was darf ich mir darunter vorstellen?
Wie kann ich in einem Link definieren, dass der Browser den Proxy
umgeht und direkt vom Internetserver lädt??Gar nicht. Abgesehen davon, daß "umgeht" noch mal etwas anderes ist als das, was Du eigentlich willst.
Ob ein Browser einen Proxy, dessen Verwendung explizit in der Browser-Konfiguration eingetragen sein kann, umgeht, ist an eben dieser Stelle der Konfiguration einstellbar. Bei Netscape/Mozilla gibt es nur eine Negativliste für Domain-Namen; der M$IE entwickelt einmal mehr "eigene Pseudo-Intelligenz" und würfelt sich eine Logik zusammen, nach welcher der Dateien "lokaler Netze" anders behandeln kann (auch das ist per Checkbox ein- und ausschaltbar) als entfernte Netze. Dies nur der Vollständigkeit halber (für's Archiv).
Aber in Deinem Fall scheint es mir nur um Caching zu gehen. Und dazu müßte Dein Server entsprechende HTTP-Header senden - noch dazu unterschiedliche für HTTP/1.0 und HTTP/1.1. Es ist wahrscheinlich sinnvoll (und viel einfacher zu realisieren), immer gleich beides zu senden, weil laut HTTP/1.1-Spezifikation ein HTTP/1.1-fähiger Client (was in diesem Falle Browser, aber auch Proxy bedeuten kann!) die HTTP/1.1-Header gegenüber den HTTP/1.0-Headern vorrangig beachten muß. Deshalb kann Dir egal sein, welchen der beiden Standards der Client beachtet.
Caching in HTTP ist ein relativ komplexes Thema; gerade wenn Du ein Spiel hast, also wahrscheinlich subjektive Informationen pro Client, gelten wieder andere Voraussetzungen als bei beliebigen normalen Webseiten. Dies alles kann man aber durch entsprechende HTTP-Header beschreiben - Du kannst dem Proxy sehr genau erklären, was er tun darf und was nicht.
Lesetip: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13 - das sind erst mal die Grundlagen, und von dort führen genügend Links weiter zu den Beschreibungen der einzelnen Headern.
Viele Grüße
Michael
(der gerade versucht, das genaue Gegenteil zu erreichen - nämlich möglichst viele Kunden-Browser auf möglichst "kooperatives" Caching = so wenig Nachfragen wie möglich zu trimmen, weil ich weiß, daß ich für die nicht cachebaren Seiten entsprechende Header mitsende.
Denn auch die ständige Überprüfung der Gültigkeit des Inhalts eines Browser-Caches kann massig Bandbreite kosten - für selfhtml.teamone.de sind es beispielsweise 10% des gesamten Traffic, also immerhin 2 GB "Luft" pro Woche ...)