Liefert new URL(String) gecachte Webseiten?

[Jaskur]

Guten Tag!
Im Rahmen eines Uni Projektes entwickle ich eine Java Software welche es ermöglicht Webseiten abzuspeichern. Es ist hierbei erforderlich immer die aktuelle Version der Webseite anzufordern und keine gecachte Version da die Software zu forensischen Zwecken verwendet werden soll.
Hierfür habe ich mir auf die Schnelle folgende Funktion geschrieben:

private String makeRequest(String requestUrl){
		
		try {
			URL url = new URL(requestUrl.toString());
	        
			StringBuffer sbSource = new StringBuffer();
			BufferedReader in = new BufferedReader(new InputStreamReader(url.openStream()));

			String inputLine;
	        while ((inputLine = in.readLine()) != null) {
	        	sbSource.append(inputLine);
	        }
	        in.close();      
	        source=sbSource.toString();
	        
	    } catch (IOException e) {
	    	System.out.println("Error occured: url.openStream()");
	        //e.printStackTrace();
	    }
	    		
		return source;
	}

Nun bin ich aber unsicher ob ich hierbei Gefahr laufe eine gecachte Version zu erhalten.
Falls ja, gibt es Möglichkeit sicher zu gehen dass dies nicht passiert?
Falls nein, müsste ich in Erfahrung bringen warum dies so ist.

 

[MQue]

Also mit dieser Klasse kann man einiges in diese Richtung feststellen:

CacheUtil (Netx v0.5 JavaDoc)

 

[Gast2]

Nun bin ich aber unsicher ob ich hierbei Gefahr laufe eine gecachte Version zu erhalten.

die Chancen stehen gut Webseiten aus dem Cache zu erhalten, wenn das Netzwerk irgendwo (beginnend am lokalem Rechnen - Ende beim Webserver) entsprechend Webseiten zwischen speichert ... die Implementierung von URL dürfe sich mit Cachen von Seiten nicht befassen

Falls ja, gibt es Möglichkeit sicher zu gehen dass dies nicht passiert?

entweder [c]?rnd=XXXXXXXX[/c] oder [c]&rnd=XXXXXXXXX[/c] an die URL hängen ... dabei [c]X[/c] jeweils durch gülte Zufallswerte ersetzen

hand, mogel

 

[tagedieb]

Du kannst im Prinzip immer Gefahr laufen eine gecachte Seite zu erhalten.

Aus Performancegruenden wird serverseitig vorgelagerte Caches verwendet um den eigentlichen Server nicht zu ueberlasten.
Normalerweise werden eher statische Resourcen wie Bilder, Sound, .css, .js,... gecached und nicht dynamische Inhalte.

Ich fuerchte du hast nicht viel Einfluss ob du das Original oder eine gecachte Version erhaelst. Wie gesagt sollten eigentlich nur statische Inhalte gecached werden, bei dennen es keine Rolle spielt. Ausserdem sind die Webseiten Administratoren die Seiten so aktuell wie moeglich zu halten und Caching nur dort zu verwenden wo es Sinn macht. Niemand hat interesse eine alte Seite zu cachen sondern sind bemueht immer die aktuellste Version zu verwenden.

 

[Michael...]

Das ist via URLConnection einstellbar:

URL url = new URL("http://java-forum.org");        	
URLConnection urlconnection = url.openConnection();
urlconnection.setUseCaches(false);
			
BufferedReader reader = new BufferedReader(new InputStreamReader(urlconnection.getInputStream()));
...

 

[homer65]

Das ist via URLConnection einstellbar:

URL url = new URL("http://java-forum.org");        	
URLConnection urlconnection = url.openConnection();
urlconnection.setUseCaches(false);
			
BufferedReader reader = new BufferedReader(new InputStreamReader(urlconnection.getInputStream()));
...

Dadurch wird der Wunsch geäußert keinen CACHE zu benutzen, ob es aber funktioniert ist durchaus nicht sicher.

 

[Jaskur]

Vielen Dank für die Antworten, ich werde nun erst einmal ein paar Dinge im Detail durchspielen, dann melde ich mich wieder zu Wort!

 

[Jaskur]

[QUOTE=""MQue]
Also mit dieser Klasse kann man einiges in diese Richtung feststellen:

CacheUtil (Netx v0.5 JavaDoc)
[/QUOTE]
Ich habe die Klasse jetzt grob überflogen und mein erster Eindruck ist, dass ich damit einen eigenen Cache anlegen und meine Version dann mit der der Ursprungs-URL überprüfen kann. Falls ja ist das leider nicht dass was ich suche, sollte ich dies falsch verstanden habe bitte ich um Korrektur

[QUOTE=""mogel]
entweder ?rnd=XXXXXXXX oder &rnd=XXXXXXXXX an die URL hängen ... dabei X jeweils durch gülte Zufallswerte ersetzen[/QUOTE]

Wenn ich an eine URL nun immer den aktuellen timestamp anhänge in Form eines GET Parameters garantiert mir dies, dass ich keine gecachte Version der Webseite erhalte?
Wie sieht es mit Ressourcen wie Bildern aus, müsste ich nicht bei jedem Bild ebenfalls einen Parameter anhängen um sicher zu gehen kein gecachtes Bild zu erhalten?

@Michael und homer65

Ich frage mich nun welches Szenario eintreten muss/kann damit ich eine unerwünschte gecachte Version erhalte und wie wahrscheinlich dies ist

Fragen über Fragen, aber mit der Thematik werde ich mich noch mindestens ein Jahr beschäftigen. Zur Zeit hoffe ich noch dass ich es irgendwie in Java realisiert bekomme

 

[homer65]

Es kann ja verschiedene Instanzen geben die Cachen.
Der Browser kann cachen.
Es könnte (wie bei uns) ein Proxy mit Cache dazwischensitzen.
Und man weiss nicht welche Netzwerkcomponenten auch cachen.
Wie soll das alles von Java aus beeinflußt werden?
Edit:
Es funktioniert solange ALLE Komponenten mitmachen.
Aber weißt du sicher, ob sich alle daran halten?
Vermutlich, weißt du noch nicht mal wer ALLE eigentlich sind.

 

[Michael...]

setUseCaches(false) bewirkt, dass im Http Header Cache-control auf no-caches gesetzt wird.
Wenn ich die Http Spezifikation richtig verstanden habe, müssen diese Cache Anweisungen durch sämtliche Proxies und Gateways durchgeroutet werden. Wie sich das in der Praxis auswirkt - keine Ahnung.

 

[Jaskur]

Um genau diese Fragen geht es mir, darum starte ich zur Zeit einige Schüsse ins Blaue und sammle Informationen.
Negative Informationen sind in meinem Fall auch gute Informationen, für mich!

Sprich ich schau jetzt einfach wie weit ich mit Java komme und zeige dann die Grenzen auf. Vor allem gehts mir ja darum das es möglichst wahrscheinlich ist keine gecachte Version zu erhalten. Eine gewisse Unsicherheit spielt natürlich immer mit.

Edit:

setUseCaches(false) bewirkt, dass im Http Header Cache-control auf no-caches gesetzt wird.
Wenn ich die Http Spezifikation richtig verstanden habe, müssen diese Cache Anweisungen durch sämtliche Proxies und Gateways durchgeroutet werden. Wie sich das in der Praxis auswirkt - keine Ahnung.

Vielen Dank, mal sehen ob ich ein Praxis taugliches Beispiel auf die Beine stellen kann.

 

[maki]

Das Problem ist kein Javaproblem und unanhängig von der genutzten Sprache

Mogels Vorschlag ist der vielversprechendste imho.

 

[homer65]

Das Problem ist kein Javaproblem und unanhängig von der genutzten Sprache

Mogels Vorschlag ist der vielversprechendste imho.

Sehe ich auch so. Zusätzlich kann der Vorschlag von Michael... auch die Quote nicht gecachter Seiten erhöhen.

 

[maki]

Ja, Michael hatte den "offiziellen" Weg beschrieben, und auch die Einschränkung/Vorraussetzung genannt:
Alle beteiligten (OS, Router, Proxies, etc.) spielen nach den Regeln

 

[Jaskur]

Vielen Dank für die vielen Antworten, jetzt habe ich wieder eine Richtung in die ich weiter arbeiten kann!

 

[Gast2]

Wenn ich an eine URL nun immer den aktuellen timestamp anhänge in Form eines GET Parameters garantiert mir dies, dass ich keine gecachte Version der Webseite erhalte?

eine Garantie hast Du bei dem Thema nie ... es kommt darauf an wie der Proxy, über den Dein Request stolpert, reagiert

Wie sieht es mit Ressourcen wie Bildern aus, müsste ich nicht bei jedem Bild ebenfalls einen Parameter anhängen um sicher zu gehen kein gecachtes Bild zu erhalten?

ja - daher ein [c]?rnd=...[/c] ... im einfachsten Fall schaut ein Proxy nur ob er die URL schon "besitzt" und liefert dann entsprechend den bei sich gelagerten Content nochmal aus (sofern die Zeit noch nicht abgelaufen ist) ... in dem Moment wo Du einen zufälligen Parameter an die URL hängst, erhälst Du eine völlig neue URL - die der Proxy noch nicht kennt ... damit holt er immer wieder fleißig alles neu vom Server - außer der Proxy "kennt" Deinen Trick ... dann kann das auch schief laufen

ich kenne das HTTP-Protokoll nicht auswendig - reichen müsste auch [c]
setUseCaches(false)[/c] ... allerdings darf der Proxy solche Einstellungen auch einfach ignorieren ... wenn Du beides nutzt sollte es sicherer sein

machen musst Du es, da ein Proxy - auch ohne entsprechende Einstellungen im Browser bzw. Deinem Wissen - im Netzwerk arbeiten kann ... und zwar in dem Moment wo alles über einen Rechner geleitet wird ... war bei der FH wo ich studiert habe am Anfang so ... keine Proxy-Einstellungen vorhanden - aber HTTP-Traffic wurde über einen Proxy geroutet ... hatte den Vorteil Susi-Sorglos in Bruchteilen von ein paar Minuten zu erhalten - sofern man nicht die aktuellste Version brauchte