“Holzwurm”, unser BSD-User, hat sicherlich auch gemäß der von ihm erstellten Anleitung zur Live-DVD den User-Account ‘webmaster’ (wenn ich mich recht erinnere) genutzt. Ich hatte ja als ‘root’ lediglich Firefox unter BSD getestet, ohne einen Proxy zu nutzen – daher sah das alles in den beiden Videos auch alles etwas unterschiedlich aus. Und deshalb hatte ich auch das Problem mit dem Fehler nicht.

Aber selbst auf Benutzerebene funktioniert der Aufruf des Shops bei ihm – zumindest, wenn er KEINEN Proxy nutzt. Dahingehend hat er sich mir gegenüber bei Facebook geäußert:

Warum und wieso das so ist, zu welchem Zeitpunkt wann warum wo was von wem abgeschippelt wird oder auch nicht bzw. welche Einstellung für dieses Verhalten verantwortlich ist, wird wohl auf ewig ein Rätsel bleiben – es sei denn, ich habe mal irgendwann die Muße, die Lust und entsprechend viel Zeit, das alles selbst noch mal MIT PROXY zu testen (und ob ich dann etwas rausbekomme, ist ohnehin fraglich…). Im Moment verspüre ich den Drang jedenfalls nicht, da die Umleitung richtig arbeitet.

Ohne Argumente finde ich zwar die Aussage “Squid spinnt auch nicht, der schnipselt nicht … einfach so was weg” etwas gewagt – denn durch den Einsatz des Proxys kommt es ja zum Fehler, bei dem der URL nachweislich verändert wird. Aber ich gebe mich an dieser Stelle einfach mal mit der markierten Passage zufrieden, da ich das Problem ja nun, von “Holzwurm” abgesegnet, auf den Proxy oder/und restriktive Einstellungen schieben “darf” – gemäß dem Motto “Was kann ich dafür, wenn ein Lynx-User keine Bilder sieht”. ;o)

Der Shop-Server “servt”, die Umleitungen leiten um, und die Browser browsen – alles so, wie es soll. Und der Rest fällt in die Kategorie “persönliches Pech”. Bis ich neue Anhaltspunkte habe, werde ich mir diese Sicht der Dinge zu eigen machen müssen.

Zumindest der heißgeliebte Proxyserver Squid (ja – ok; gibt es auch für Windows…) beherrscht je nach Randbedingungen aka Konfiguration das Verstümmeln von URLs perfekt – auch, wenn nur am anderen Ende des Adreßstrings rumgeschnippelt wird: http://debianforum.de/forum/viewtopic.php?f=18&t=14586
Und rein zufällig wirft dort ein nicht aufrufbarer URL einen Fehler der 4er-Klasse… Ok, 400 bedeutet zwar nicht “404 – Seite nicht gefunden” – aber als “Sammelcode” immerhin noch so viel wie “Häh? Doof? Kenne ich nicht, kann oder will ich nicht aufrufen…”.

Also ich für meinen Teil vermute dahinter eine weltweite Verschwörung…

Und? Schon irgendwas getestet? Oder ist Dir das zu doof, weil ich Dir immer noch (sogar bzw. erst recht nach Deinem Beweisvideo) die clientseitige Verursachung eines Serverfehlers in die Schuhe schiebe ??? Ich gebe zu: Erzählen darf man das wirklich niemandem. Sonst denkt derjenige womöglich noch, ich hätte in Putbus gelernt…
;o) ;o) ;o)

####################################################

Hallo Heiko,

danke für die Antwort. Ok, mit der URL-Eingabe in die Adreßleiste lag ich falsch. Aber ich kann ja nicht ahnen, daß Du Deinen Browser soweit abwürgst, bis nichts mehr geht – sofern Du dafür verantwortlich bist.

Kann ja auch sein, daß er ’ne Macke hat. Allerdings sollte es ja die gleiche Version sein, die ich auf Deiner Proxy-CD genutzt habe. Aber ich war nicht als „webmaster“ sondern als „root“ angemeldet. Du hast ja gesehen – bei mir sah es etwas anders aus. Ich wollte auch nur wissen, ob FF@BSD in der Lage ist, die Seite aufzurufen. Und das funzt – wie erwartet!

Der Rest liegt eben (wie Du schon selbst sagst) an Deinen Einstellungen!

Leider ist im Video alles sehr klein, so daß ich die Header nicht lesen kann. Daher habe ich selbst mitgeschnitten.

Aber: Ich sehe im Video ellenlange Zeichenketten, die auf per URL übergebene Session-Ids (wegen der Sparte der paranoiden Cookie-Verweigerer *lol*) hinweisen bzw. wie welche aussehen. Header scheinen also ok zu sein.

Und damit hat Dein Browser scheinbar ein Problem – mal davon abgesehen, daß er aus /shop.php einfach /shop macht.

Ich hatte z.B. mit Deiner Proxy-Scheibe immense Probleme, TRISEPO.COM aufzurufen. Erste Seite ging normal; alle anderen Seiten durfte ich erst per [STRG] + [F5] „zwangsaktualisieren“, weil ich nur die Textansicht bekam und die CSS scheinbar nicht geladen oder abgearbeitet wurden. Proxy ausgeschaltet – und alles funktionierte normal.

Also: Was passiert, wenn Du den Proxy ausschaltest? Tritt das Problem dann trotzdem auf? Teste mal bitte 1-8 mit Deiner aktuellen Rechnerkonfiguration und dann ohne Tor/Proxy. Und bitte mal alles halbwegs protokollieren (z.B. kompletten Header-Mitschnitt). Was passiert bei Direkteingabe von
1) http://shop.hbz-branse.de
2) http://hbz-shop.de
3) http://hbz-branse-shop.de
4) http://shop.hbz-branse.de/shop.php
5) http://shop.hbz-branse.de/index.php
6) http://shop.hbz-branse.de/index.php?page=Shop
7) Deine Seite als Vergleich heranzuziehen bringt leider gar nichts. Zumindest sehe ich keinerlei Session-Ids, die per URL übergeben werden. Wenn, dann leg einen Link auf eine shop.html an und schreibe dafür in der .htaccess eine RewriteRule mit Redirect auf http://shop.hbz-branse.de. Dann solltest Du eigentlich bei gleichen Einstellungen dasselbe Problem bekommen – Deine Seite wäre dann genauso „buggy“.
8) Scherzhalber kannst Du ja auch eine shop2.html anlegen und in der .htaccess mal direkt auf http://shop.hbz-branse.de/shop.php umleiten. Wenn das wider Erwarten bei Deinem FF@BSD nicht zum 404er führt, ist das ein Indiz für 2 mögliche Bug-Szenarien: Entweder kommt Dein Rechner nicht mit den SessionIDs im URL klar – oder er kommt bei zwei aufeinanderfolgenden 302ern (bzw. jetzt 301/302) aus dem Tritt. Selbst das wäre der Beweis, daß das Problem an Deinem Ende der Leitung liegt.

Der Gag ist, daß bei Minute 01:56 in Deinem Video die richtige Seite (/shop.php nebst SessId im URL) aufgerufen wird. Und bei 02:05 springt der Browser auf /shop zurück. Schon mal bei 1:57 – 2:04 versucht, per [Strg][F5] einen am Proxy vorbeigehenden Reload zu erzwingen???

Der 404er weist zwar auf ein serverseitiges Problem hin – aber letztendlich ist er richtig, wenn ein nicht existenter URL aufgerufen wird. Aber der kommt eben durch den Browser bzw. Deine Einstellungen zustande – wie und warum auch immer.

Ich habe alles ausgeschaltet – Referrer, Cookies, sogar Session-Cookies, JavaScript, Cache und selbst die Meta-Redirects, obwohl letztere ja gar nichts mit dem Problem zu tun haben (können). Und es funzt! Was hast Du also alles bei Tor und Konsorten verbogen, damit es nicht geht?

Wenn Du im Header einen URL mit Session-Id findest, kopiere ihn mal in die Adreßleiste und rufe ihn auf. Was passiert dann?

Der URL, den Dein Browser mit Deinen Einstellungen aufruft, ist nirgends auf dem Server hinterlegt – behaupte ich jetzt einfach mal. (Ich habe keinen Zugriff auf den PHP-Code!)

Wieso verstümmelt bzw. MANIPULIERT Dein Firefox dann bitteschön einfach so die Adresse?

Im Header-Mitschnitt ist kein einziger 404 zu entdecken.

Und die ersten 4 Blöcke (ich müßte mich sehr irren, wenn es anders wäre) deuten darauf hin, daß http://www.hbz-branse.de/shop.html eine Weiterleitung (bis eben 302/temporär – geändert in 301/permanent wegen PR-Vererbung – aber das ist ja wohl irrelevant) auf die Subdomain http://shop.hbz-branse.de macht, wodurch dort versucht wird, die Default-Seite (default.*/main.*/index.*) aufzurufen. Das führt automatisch zum Aufruf der index.php, die aber nicht gesondert im Header-Mitschnitt auftaucht, da sie darin unter http://shop.hbz-branse.de bereits erfaßt wurde. Wenn ich mich recht erinnere, konnte man damit eine Wartungs-Vorschaltseite ins Netz stellen; ansonsten (also jetzt) wird darin eine Session gestartet und per header-Funktion standardgemäß eine 302-Weiterleitung ausgelöst:


session_start();
if (isset($_GET['page']) && $_GET['page'] != '') {
if (isset($_GET['SessID']) && $_GET['SessID'] != '') {
include($bla);
} else {
header("Location: /index.php?page=" . $_GET['page'] . "&SessID=" . session_id());
}
} else {
header("Location: /shop.php?SessID=" . session_id());
}


So in etwa stelle ich mir den Code vor.

Zumindest funktioniert das als Test-Script und würde erklären, warum ein Direktaufruf der http://shop.hbz-branse.de/shop.php nicht dazu führt, daß eine SessID angefügt wird.

Wenn Du jetzt ehrlich bist und Dein Gehirn mal richtig doll anstrengst, siehst Du selbst, daß das, was bei Dir passiert, eigentlich gar nicht passieren kann !!!

Es MUSS also an Deiner Konfiguration liegen – oder daran, daß diese einen Fehler in der Browsersoftware verursacht. Ich traue restriktiven Einstellungen zu, daß sie Querystrings oder SessionIDs entfernen – aber aus /shop.php nur /shop zu machen DARF NICHT passieren!

Ich bleibe daher (trotz serverseitigen 404ers + Videobeweis) dabei, daß das Problem NICHT bei Branse oder beim Shop liegt!

So, ich wünsche Happy Testing…
Bin auf Deine Ergebnisse gespannt! Danke.

PS: Willkommen bei 3SEPO@Blog!

• http://www.mimikama.at/facebook-tipps-und-tricks/info-zu-hallo-wie-ihr-wisst-mchte-ich-mein-fb-privat-halten-auer-mit-meinen-freunden/

• http://www.mimikama.at/hoax-meldungen/hoax-fahre-mit-der-maus-ber-meinen-namen/

• http://www.facebook.com/fakepostings/posts/285617168210880

• http://onsoftware.softonic.de/facebook-kann-jeder-sehen-was-mir-gefallt

• http://www.marblicksweg.de/facebook/facebook-posts-sind-nicht-offentlich/

Reicht es noch nicht? Dann kopiert die ersten Worte/Sätze dieser schwachsinnigen Info ins Google-Suchfeld und klickt den Button daneben…

Oder Ihr besucht diese Seite:

• http://www.facebook.com/fakepostings/posts/214373568624670

Dieser letzte Link ist eigentlich der wichtigste; führt er doch zu folgendem Post:

ACHTUNG!!!!!!! WICHTIG!!!!! ACHTUNG!!!!! WICHTIG!!!!!
Klicke auf “Konto”, “Kontoeinstellungen”, “Sicherheit (links)” und dann auf “Deaktiviere dein Konto”. Nur so kannst du herausfinden, ob du auch zu denjenigen gehörst, die jeden Schwachsinn ohne Nachzudenken befolgen und weiterverbreiten.

Schalte ich bei Mr. Nobody das Gewünschte aus, erscheinen in MEINEN Neuigkeiten keine Mitteilungen mehr, was Mr. Nobody macht. Unabhängig davon sieht aber JEDER, der den Ursprungspost auf der Seite von John Doe aufruft, Mr. Nobodys Antwort, unabhängig davon, was ich irgendwo einstelle. Einzige Möglichkeit das zu verhindern: Mr. Nobody stellt über SEINE Privatsphäreneinstellungen ein, daß nur SEINE Freunde seine Posts lesen dürfen…