Nichts als heiße Luft…


Nachdem wegen angeblicher Fehler im Online-Shop der HBZ Branse GmbH viel heiße Luft durch einen BSD-User abgelassen wurde und wir  hier und hier darauf eingingen, lief viel Wasser den Berg hinunter – immerhin haben wir die haltlosen Vorwürfe über ein Vierteljahr unkommentiert gelassen.

Wir erinnern uns kurz: Die “Startseite” http://shop.hbz-branse.de/shop erzeugte einen Fehler 404. Der Gag dabei: Das ist nicht die Startseite! Und es existiert auch keine Umleitung, die diesen Aufruf erzeugt! Für uns war klar: Der Fehler sitzt vor dem Monitor in Schicht 8 des siebenschichtigen OSI-Modells. Immerhin war der BSDler stolz auf seine “speziellen Einstellungen”. Nun war es aber an uns, herauszufinden, was mit “normalen Einstellungen” (bzw. bei “normaler Nutzung”) passiert. Was geschieht also, wenn man den Browser bestimmungsgemäß verwendet und nicht einfach irgendwelche Phantasie-URLs zu nicht existenten Seiten eingibt?

Erstens hätten wir zum Testen mit besagter BSD-Edition ein 64Bit-System gebraucht. Davon gibt es bei uns zwar etliche – als Fätt-Boys haben wir schließlich 2 DiMuX(e) im Einsatz. Doch die sind logischerweise tabu. “Never touch a running system” vs. Live-Stick… Nö – beim besten Willen nicht. Nicht wegen derartigen Unsinns… Privat steht beim Kollegen Klein auch etwas 64bittiges herum – er hat aber auch noch etwas anderes zu tun; und das nicht zu knapp. Private Kisten oder Rechner mit anderer Bestimmung a la DiMuX sind ohnehin irgendwie tabu. Außerdem: Bei EiTiCo bin ich der Web-Onkel – aber meine 64er Test-Kiste war leider gerade “out of order”. Seit über 3 Monaten lag das Ding in auseinandergeschraubten Einzelteilen irgendwo hier und dort verteilt umher, weil es nicht so wollte, wie es sollte. Endlich habe ich auch in einer ruhigen Minute die Fehlerquelle gefunden: Eine meiner heißgeliebten M-Audio Delta 1010LT war verstorben. Rien ne va plus – nichts geht mehr! Ok, kurz getrauert; alles zusammengefriemelt, dann fix den originalen, “popeligen” Realtek-HD-Sound@NVIDIA aktiviert – und dat Ding löppt allwedder…

Zweitens: Ich hatte die Ruhe weg! Denn SERVERSEITIG heißt SERVERSEITIG! Und kraft meiner Wassersuppe habe ich im Vollbesitz meiner geistigen Fähigkeiten SERVERSEITIGE UMLEITUNGEN per .htaccess erstellt. Also konnte der besagte Fehler gar nicht auftreten – es sei denn, der Feuerfuchs der betreffenden BSD-Edition macht, was er will und kreiert nach Belieben URLs, die er dann aufruft. Doch dann wäre er komplett Schrott und nicht nutzbar; das würde dieses System komplett disqualifizieren. Daher war dieser Teil der Kritik (SSL-Kritik ist berechtigt! Liegt aber nicht in meiner Hand!) von Anfang an einfach nur in die Kategorie BLÖDSINN einzuordnen.

Drittens: Die einzige Möglichkeit, die (neben mutwilliger URL-Falscheingabe seitens des testenden “anonymen BSD-Users” (kurz: “ABU”)) zu einem Auftreten des Fehlers führen könnte, wäre ein von mir irgendwo eingebauter, falscher Link, der keine Umleitung auslöst und direkt auf den falschen URL zeigt. Doch ich bat ja den ABU, mir mitzuteilen, wo er den URL her hätte (um diesen etwaigen Fehler dann auszumerzen). Bislang ist diesbezüglich nichts erfolgt. Also bleibt mir nur die Annahme, daß er diese Adresse höchst-selbst und eigenhändig eingetippselt hat.

Doch DANN ist alles ok – wie erwartet. Nicht existente Seiten liefern nun einmal einen 404er; das soll so, muß so und ist auch richtig so. Das weiß eigentlich sogar der ABU. Die serverseitigen Umleitungen funktionieren alle perfekt – wie erwartet. Und nun kann ich auch reinen Gewissens sagen, ich hätte es mit BSD getestet:

Sowohl alle Verlinkungen auf der Homepage als auch die Direkteingabe von  http://shop.hbz-branse.de/, http://www.hbz-shop.de/ oder http://www.hbz-branse-shop.de/ führen erwartungsgemäß zur richtigen Seite. Lediglich ein Flash-Element wird vom “Gnash”-Player unter BSD nicht verarbeitet. Aber Flash ist ohnehin (spätestens seit HTML5 und Apple-Smartphones) out und stirbt demnächst sowieso.

Aber von einem 404er ist weit und breit nichts zu sehen – der tritt erst auf, wenn ich Phantasie-URLs wie /shop oder /wurstbrot eingebe. Doch so was mache ich nicht - ich bin schließlich kein ABU!

Wie gesagt: Falls ich den (übrigens logischerweise natürlich auch in anderen Browsern einen Fehler 404 erzeugenden) URL irgendwo so, wie es kritisiert wurde (http://shop.hbz-branse.de/shop), fälschlicherweise verlinkt haben sollte, ist mir das echt entgangen. Gefunden habe ich jedenfalls nichts. Doch so lange sich der ABU in Schweigen hüllt, muß ich eben annehmen, daß er seine hyperaktiven Fingerchen bei der Adreßeingabe nicht im Griff hatte. Doch mit Verlaub – das ist dann einzig und allein SEIN Problem und interessiert mich nicht die Bohne.

Nach wie vor bin ich aber gern bereit, das (angebliche) Problem hier im Blog zu diskutieren oder ggf. zu reproduzieren. So lange man mir aber nicht den geheimen und gut versteckten Link auf die angebliche Startseite zeigt, bleibe ich um so standhafter bei meiner Meinung, daß alles so ist, wie es sein soll.

Offizielles Fazit: Der kritisierte Fehler existierte nie und ist nur heiße Luft - mehr nicht! Und alles, was zu der Annahme dieses Fehlers führte, basierte auf falschem Umgang mit dem Rechner – so leid es mir auch für das Ego des BSD-Nerds tut.

Update: Ich habe gerade festgestellt, daß neben dem, was im Blog niedergeschreiben steht, noch eine weitergehende Diskussion stattfand und mir doch vom ABU mitgeteilt wurde, in welcher Situation der Fehler auftritt – das war mir in Anbetracht der verstrichenen Zeit tatsächlich entfallen. Wenn ich ihn richtig verstanden habe, tritt der 404er auf, wenn man in der Navigationsleiste der Homepage auf Shop klickt. Daher habe ich sämtliche Verlinkungen nochmals getestet – und zwar für alle als Video sichtbar und nachvollziehbar.

4 Gedanken zu “Nichts als heiße Luft…

  1. Für alle diejenigen, die das Video auch nicht auf der Seite sehen können:
    VIDEO-Download

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

    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!

  2. Interessant: Die OS-Developer der Sparte /^(Li|U)[n][ui][x]$/ und die derer Derivate scheinen wohl prinzipiell etwas gegen fremd-kreierte URLs zu haben und gehen mit ihren Tools/Progs gnadenlos dagegen vor… *lol*

    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)

  3. Nachdem nun wieder einige Zeit vergangen ist und keine Rückmeldungen mehr kommen, gibt es an dieser Stelle einen (vorläufigen) Abschlußbericht: Es liegt – wie schon vermutet – am Proxyserver bzw. an dessen Verwendung. Der Serverfehler beim Shop kommt durch clientseitige URL-Manipulation zustande, wobei der Proxy die Rolle des Clients übernimmt.

    “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:

    Statement von Holzwurm (per Facebook)

    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.

Hinterlasse eine Antwort