Problem mit gesperrten Seiten durch Proxies, Smartfilter ...

MainziMan

Zitat von .Ulli

Immer noch nicht nachvollziehbar.
[Blockierte Grafik: http://www.imagebanana.com/img/kev65605/thumb/BildschirmfototestMinefield.png]
Die dabei benutzte naive Blockade:

der HTTP-Header stimmt schon, der wird auch bei mir so geliefert, nur wie verhält sich Dein Browser?
wenn Du folgenden URL probierst: https://www.googleadservices.com/ ?
zeigt er eine Firefox eigene Fehlerseite oder die des Proxies an?
nebenbei: Du werkst unter Linux, hier sieht die Welt auch anders aus; probier den Firefox unter Windows;
solche Verhaltensmuster, welche unter dem einen Betriebssystem zu finden sind, müssen nicht auch auf anderen
Betriebssystemen zu finden sein;

mein System: WinXP Pro mit SP3 und verwendeter Benutzer hat keine administrativen Rechte;

kann es sein, daß die Firefox eigene Fehlerseite, welche hier bei mir kommt, die Ursache ist,
und im Falle von solchen Verlinkungen, es nicht möglich ist den "Try again" od. "Nochmals versuchen" Button niemand drücken kann, und er somit ewig wartet?

so sieht es mit Firefox aus:

[Blockierte Grafik: http://img36.imageshack.us/img36/8757/firefoxscreen.th.png]

so aber mit Netscape:

[Blockierte Grafik: http://img411.imageshack.us/img411/3577/netscapescreen.th.png]

der IE zeigt in der Version 8 ebenfalls einen eigenen Dialog, kann aber damit umgehen, sollte so eine Seite versteckt dargestellt werden;

.Ulli

Zitat von MainziMan

nur wie verhält sich Dein Browser?

Wie es erwartet wird

[Blockierte Grafik: http://www.imagebanana.com/img/6zld7xva/thumb/BildschirmfotoFEHLERNamoroka.png]

Zitat von MainziMan

Du werkst unter Linux, hier sieht die Welt auch anders aus; probier den Firefox unter Windows

Auch hier wie erwartet

[Blockierte Grafik: http://www.imagebanana.com/img/c2hlqv9/thumb/BildschirmfotoxpwirdausgefhrtSunVirt.png]

Klar, der Fx unter Linux bleibt von diversen "Hilfsanwendungen" verschont, aber auf dieser Ebene gibt es keine Unterschiede.

Es waren aber neue Profile im Rennen.

MainziMan

Zitat von .Ulli

Auch hier wie erwartet
[Blockierte Grafik: http://www.imagebanana.com/img/c2hlqv9/thumb/BildschirmfotoxpwirdausgefhrtSunVirt.png]
Klar, der Fx unter Linux bleibt von diversen "Hilfsanwendungen" verschont, aber auf dieser Ebene gibt es keine Unterschiede.

und mit https?

.Ulli

Zitat von MainziMan

und mit https?

Habe ich doch das kleine s bislang glatt übersehen.

https ist eine ganz andere Ebene, auf der vor einem Datenaustausch erst die Zertifikate ausgetauscht / überprüft werden. Da kann der Squid von der Stange nicht sinnvoll mithalten. Darum erfolgt die Abweisung auf Protokollebene, die der Fx dann mit einer eigenen Meldung reflektiert.

MainziMan

bei HTTPS Verbindungen, welche geblockt werden finde ich im Log von Squid
/var/log/squid/access.log z.B. folgendes:

Code

1269345010.008      4 192.168.23.1 TCP_DENIED/403 1374 CONNECT www.googleadservices.com:443 - NONE/- text/html

im Unterschied zu HTTP

Code

1269345699.995    644 192.168.23.1 TCP_DENIED/403 1382 GET http://www.googleadservices.com/ - NONE/- text/html
1269345700.013     17 192.168.23.1 TCP_DENIED/403 1404 GET http://www.googleadservices.com/favicon.ico - NONE/- text/html

.Ulli

Ist bekannt - was möchtest du damit aussagen ?

MainziMan

Zitat von .Ulli

Ist bekannt - was möchtest du damit aussagen ?

daß Du obigen HTML-Code in einen HTML File kopierst und unter Windows
mit Firefox öffnest, und damit das Problem nachvollziehst;

boardraider

Quelle: MainziMan

Zitat von MainziMan

Ohne einen Proxy, welcher http://www.googleadservices.com sperrt, läßt sich das Problem ohnehin nicht reproduzieren;

Der Proxy war der Knackpunkt. Auf Grund deiner Aussage oben ging ich zunächst davon aus, dass du dem Fx ein generelles Problem mit 403-Antworten auf JS-Referenzen unterstellst.
Problem für Proxies ist bereits erfasst:
https://bugzilla.mozilla.org/show_bug.cgi?id=492459
Dürfte damit zusammen hängen:
https://bugzilla.mozilla.org/show_bug.cgi?id=479880

MainziMan

Zitat von boardraider

Problem für Proxies ist bereits erfasst:
https://bugzilla.mozilla.org/show_bug.cgi?id=492459
Dürfte damit zusammen hängen:
https://bugzilla.mozilla.org/show_bug.cgi?id=479880

genau das ist es ...
nur daß 492459 auch für Windows gilt - ich hab' ja das Problem unter Windows festgestellt;

.Ulli

Zitat von MainziMan

und damit das Problem nachvollziehst;

Dein Problem kann ich nicht nachvollziehen, das Verhalten habe ich doch bereits bestätigt.

Zitat von .Ulli

Darum erfolgt die Abweisung auf Protokollebene, die der Fx dann mit einer eigenen Meldung reflektiert.

Falls es nicht klar ist, dann noch einmal: Es gibt zwischen den Plattformen keinerlei abweichendes Verhalten.

boardraider

Wie .Ulli schon schrieb, ist die Verarbeitung hier plattformneutral. Das Problem tritt auch unter anderen Betriebssystemen (bspw. Linux) auf.

.Ulli

Zitat von boardraider

Problem für Proxies ist bereits erfasst:

Wobei mir der aktuelle Zustand sinnvoll erscheint.

Fx darf von sich aus den SSL-Kontext nicht brechen. Somit darf der Proxy die naive Blockierung dieser Art und Weise nicht benutzen.

Brummelchen

boardraider

Zitat

These trackers seem to have switched from http to https lately.

Ist eigentlich auch klar, wenn man sich man sich diverse Proxy und deren Arbeitsweise vor Augen hält.
Deswegen ja auch Anfangs der Hinweis, Unerwünschtes richtig zu "filtern", nicht auf ne Warteschleife zu setzen.
Solche Tools arbeiten auch Hand in Hand mit Proxyservern. Muss man nur wissen wollen und nicht per se stur
stellen, weil man auch dem vermeintlich richtigen Weg sich glaubt.
Warum Mozilla dieses Verhalten geändert hat, bleibt abzuwarten als Statement.

boardraider

Quelle: MainziMan

Zitat von MainziMan

eben darum hab' ich ja den Proxy, damit der Schrott schon vorher gar nicht
reinkommt ...

Quelle: MainziMan

Zitat von MainziMan

genau das bewirkt mein Proxy;
im Unterschied zu Adblock ..., bei mir geht gleich gar kein Request zu - von mir nicht gewünschten Hosts;
und damit kommt auch kein unsinniger Datenmüll retour;

An der Stelle sollte man auch ABP nochmals in Schutz nehmen. Das ist (im Sinne der Bandbreite) effektiver als die Proxy-Lösung. Die Proxy-Lösung erfordert mindestens die Anfrage zum Proxy. ABP erzeugt erst gar keine Anfrage. Die Fakten sind hier also etwas anders als unterstellt und behauptet.

boardraider

Quelle: Brummelchen

Zitat von Brummelchen

Warum Mozilla dieses Verhalten geändert hat, bleibt abzuwarten als Statement.

Dürfte in oben genanntem Bug-Report begründet sein.

boardraider

Quelle: .Ulli

Zitat von .Ulli

Wobei mir der aktuelle Zustand sinnvoll erscheint.
Fx darf von sich aus den SSL-Kontext nicht brechen.

Den Body der 403-Antwort zu verwerfen halte ich ebenfalls für gangbar. Aber das Problem ist in dem oben genannten Beispiel, dass der Fx die weitere Verarbeitung der Seite abbricht. Dies ist im Kontext von HTTP und Third-Party-Skripten fragwürdig und unnötig.

Brummelchen

Dann muss ich passen, das war mir einfach zuviel geballter Tech-Talk in englisch.
Ich hab nur was von Adam Barth vernommen, der was von einen Artikel bzgl
Sicherheit beim IE mirmelte, dass auch hier gültig wäre.
Chromium zeigt(e) ja selbiges Verhalten nach deren Aussagen.

.Ulli

Zitat von boardraider

[...] dass der Fx die weitere Verarbeitung der Seite abbricht.

Auch das konnte hier nicht nachvollzogen werden.

Zitat von boardraider

Dies ist im Kontext von HTTP und Third-Party-Skripten fragwürdig und unnötig.

Richtig, jedoch stellt sich besagte Seite hier so dar ...

[Blockierte Grafik: http://www.imagebanana.com/img/ku9hr1a/thumb/BildschirmfotoMotherboardMinefield.png]

D.h. die eingestellten Blockaden bewirken zumindest hier keine spürbare "Verhaltensänderung" des Fx.

Brummelchen

In httpS getestet, wie gewünscht wurde?

.Ulli

Zitat von Brummelchen

In httpS getestet, wie gewünscht wurde?

Muss ich also doch die Grafik erläutern.

Der URL der besagten Seite und des Quelltext sind blau unterstrichenen. Im Quelltext ist der gewünschte https-Link rot unterstrichen und der blockierende Ausdruck ist rot markiert.
Fx zeigt in der Statusbar ein zufriedenes "Done".