Sven Rautenberg: Wann schickt ein Browser ein empfangenes Cookie zurück?

Moin!

Ich könnte mal die argumentative Kraft von Fakten gebrauchen für eine eigentlich relativ simple Frage:

Wann schickt ein Browser ein in einem Request empfangenes Cookie an den Server zurück?

Diese Frage ist so, wie sie da steht, natürlich klar zu beantworten: Beim nächsten Request.

Aber: Der nächste Request ist ja, wenn in einer HTML-Seite andere Ressourcen eingebunden sind, schon bei genau diesen Ressourcen. Bzw. diese Ressourcen könnten auch erst ein Cookie setzen - was ist dann mit den weiteren Ressourcen auf der Seite.

Ein konkretes Beispiel: Eine HTML-Seite lädt zwei Javascripte. Der Request auf beide Skripte wird auch mit "Set-Cookie" beantwortet, die HTML-Seite selbst bleibt cookie-frei.

Was ist das von euch erwartete Verhalten für den Request nach dem zweiten Javascript?

a) Die im ersten Request gesetzten Cookies werden beim zweiten Request schon mitgesendet.
b) Der zweite Request sendet keine Cookies - das passiert erst nach einem Reload der HTML-Seite.
c) Anderes (Bitte angeben: ________)

Spannend wäre es auch, wenn ihr, nachdem ihr eine Vermutung geäußert habt, das mal in eurem/n Lieblingsbrowser/n verifiziert. Ich habe schon eigene Antworten für Firefox und Opera auf Windows, die ich für interessant halte. Insbesondere interessiert mich auch, ob das jeweils feststellbare Verhalten der Browser schon (in relevanten Supportforen) zu Beschwerden geführt haben, bzw. ob das unter den zuständigen Entwicklern schon mal diskutiert wurde.

Ich persönlich hatte eine Favoritenantwort, und mein Lieblingsbrowser hat sich erwartungskonform verhalten. Der andere Browser hat allerdings für eine Überraschung gesorgt.

Ich danke für jegliche Mithilfe. :)

- Sven Rautenberg

  1. Hi,

    Wann schickt ein Browser ein in einem Request empfangenes Cookie an den Server zurück?

    Diese Frage ist so, wie sie da steht, natürlich klar zu beantworten: Beim nächsten Request.

    Stimmt, klingt erst mal sehr simpel.

    Aber: Der nächste Request ist ja, wenn in einer HTML-Seite andere Ressourcen eingebunden sind, schon bei genau diesen Ressourcen. Bzw. diese Ressourcen könnten auch erst ein Cookie setzen - was ist dann mit den weiteren Ressourcen auf der Seite.

    Ich würde sagen - „es kommt drauf an.“

    Kommt drauf an, ob der Browser die Requests nach diesen Ressourcen parallel absetzt, oder einen nach dem anderen. Und bei letzterem dann noch mal darauf, ob er den jeweils nächsten schon startet, sobald die Datenübertragung des vorherigen abgeschlossen ist, oder ob er diesen auch erst noch auswertet.

    Ein konkretes Beispiel: Eine HTML-Seite lädt zwei Javascripte. Der Request auf beide Skripte wird auch mit "Set-Cookie" beantwortet, die HTML-Seite selbst bleibt cookie-frei.

    Letzteres bedeutet - Pfadangabe des Cookies enthält ein tiefer liegendes Verzeichnis? (Oder nur, dass diese Ressource selber keinen Cookie setzt?)

    Was ist das von euch erwartete Verhalten für den Request nach dem zweiten Javascript?

    a) Die im ersten Request gesetzten Cookies werden beim zweiten Request schon mitgesendet.
    b) Der zweite Request sendet keine Cookies - das passiert erst nach einem Reload der HTML-Seite.
    c) Anderes (Bitte angeben: ________)

    Siehe oben, ohne das genauere Verhalten der Browser zu studieren (oder schon zu kennen), was die Parallelität von solchen Requests und deren Auswertung angeht, kann ich dazu nur KDA sagen.

    (Hinzu kommt noch, dass Attribute wie async oder defer sich entscheidend auswirken könnten - nicht, dass ich dir unterstellen wollte, uns deren Einsatz verheimlicht zu haben.)

    Spannend wäre es auch, wenn ihr, nachdem ihr eine Vermutung geäußert habt, das mal in eurem/n Lieblingsbrowser/n verifiziert. Ich habe schon eigene Antworten für Firefox und Opera auf Windows, die ich für interessant halte.

    Die beiden hätte ich jetzt auch als erstes getestet - aber das spar ich mir jetzt.

    Ich persönlich hatte eine Favoritenantwort, und mein Lieblingsbrowser hat sich erwartungskonform verhalten. Der andere Browser hat allerdings für eine Überraschung gesorgt.

    Ich bin gespannt ... (aber gerade zu faul/müde, um eigene Tests anzustellen.)

    MfG ChrisB

    --
    RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
    1. Moin!

      Aber: Der nächste Request ist ja, wenn in einer HTML-Seite andere Ressourcen eingebunden sind, schon bei genau diesen Ressourcen. Bzw. diese Ressourcen könnten auch erst ein Cookie setzen - was ist dann mit den weiteren Ressourcen auf der Seite.

      Ich würde sagen - „es kommt drauf an.“

      Hehe, das ist natürlich eine mögliche Antwort, aber in der Diskussion noch nicht so zielführend.

      Kommt drauf an, ob der Browser die Requests nach diesen Ressourcen parallel absetzt, oder einen nach dem anderen. Und bei letzterem dann noch mal darauf, ob er den jeweils nächsten schon startet, sobald die Datenübertragung des vorherigen abgeschlossen ist, oder ob er diesen auch erst noch auswertet.

      Gerade bei Javascript ist das mit der Parallelität ja relativ klar: Javascript wird seriell geparst, deshalb werden die Requests - so jedenfalls meine Erwartung - schön nacheinander abgearbeitet. Und zwar das zweite Javascript erst dann, wenn das erste Javascript komplett angefordert und geparst im Speicher des Browsers liegt.

      Aus genau diesem Grund der Serialität von JS-Requests wird ja empfohlen, Javascript aus Performancegründen am SeitenENDE einzubinden, wenn schon das meiste im DOM geladen ist und angezeigt wird, während die spezielle Funktionalität noch am Laden ist. Die zweite Empfehlung ist, die Anzahl der Javascripte möglichst gering zu halten - aber das Beispiel lässt sich jetzt leider in der Diskussion nicht so drehen, dass man statt zwei Requests nur noch einen hat. ;)

      Ein konkretes Beispiel: Eine HTML-Seite lädt zwei Javascripte. Der Request auf beide Skripte wird auch mit "Set-Cookie" beantwortet, die HTML-Seite selbst bleibt cookie-frei.

      Letzteres bedeutet - Pfadangabe des Cookies enthält ein tiefer liegendes Verzeichnis? (Oder nur, dass diese Ressource selber keinen Cookie setzt?)

      Geh davon aus, dass die Cookies grundsätzlich an jede der hier involvierten Ressourcen zurückgeschickt werden würde, sofern es denn getan wird. Eine Einschränkung aufgrund von nichtpassender Domain, Pfad, Expire-Zeit etc. soll für die Betrachtung ausgeschlossen bleiben.

      (Hinzu kommt noch, dass Attribute wie async oder defer sich entscheidend auswirken könnten - nicht, dass ich dir unterstellen wollte, uns deren Einsatz verheimlicht zu haben.)

      Keine solche Attribute wären im Spiel.

      Spannend wäre es auch, wenn ihr, nachdem ihr eine Vermutung geäußert habt, das mal in eurem/n Lieblingsbrowser/n verifiziert. Ich habe schon eigene Antworten für Firefox und Opera auf Windows, die ich für interessant halte.

      Die beiden hätte ich jetzt auch als erstes getestet - aber das spar ich mir jetzt.

      Interessant für mich wären Browser auf Mac OS, Safari, Chrome, und gerne auch auf Mobilgeräten wie IPhone und Android (wobei das bei letzteren mit der Debug-Konsole wohl schwierig wird).

      Wobei... das Testszenario sollte man mit passendem Skripteinsatz eigentlich auch clientseitig offensichtlich darstellen können.

      - Sven Rautenberg

      1. Hi,

        Aus genau diesem Grund der Serialität von JS-Requests wird ja empfohlen, Javascript aus Performancegründen am SeitenENDE einzubinden

        Stimmt - laut PageSpeed, YSlow & Co. blockiert ein Scriptrequest ja das komplette weitere Parsen des DOM (muss er ja quasi auch, solange document.write erlaubt ist) - also käme der Browser während des Ladens und Ausführens des ersten Script noch gar nicht dazu, das zweite Script-Element überhaupt auszuwerten. (Sofern keine besonderen Attribute angegeben, aber das hast du ja ausgeschlossen.)

        <abschweif>
        Wobei das aber irgendwie bedeuten würde (so es denn eine bewusste Implementierung war), dass das Verhalten eines Browsers, den Cookie des ersten Scriptrequests nicht mit dem zweiten schon wieder mitzuschicken, einer Art Philosophie entsprungen sein müsste, die Anforderung eines HTML-Dokumentes und darin eingebundener Ressourcen als einen „Request-Zyklus“ zu betrachten, der in sich abgeschlossen ist - Cookies werden dann erst beim nächsten solchen Zyklus mitgesendet.
        Aber eine solche Philosophie wiederum, so sie denn bei der Implementation von XMLHttpRequest konsequent beibehalten worden wäre, würde AJAX in Kombination mit Cookies vermutlich derart in die Parade fahren, dass uns dann die von dir angefragten Entwickler-Diskussionen bzw. Bug-Reports nicht kollektiv entgangen wären.
        </abschweif>

        Interessant für mich wären Browser auf Mac OS, Safari, Chrome, und gerne auch auf Mobilgeräten wie IPhone und Android (wobei das bei letzteren mit der Debug-Konsole wohl schwierig wird).

        Sorry, mit dem meisten davon kann ich nicht dienen; höchstens Browser unter Win 7, und da auch keine echten Exoten.

        Wobei... das Testszenario sollte man mit passendem Skripteinsatz eigentlich auch clientseitig offensichtlich darstellen können.

        Oder auch bspw. per browsershots.org auf breiterer Testbasis visualisieren lassen*, wenn man die JavaScripte serverseitig danach verändert, ob sie einen Keks erhalten haben, und sie dies dann im Dokument ausgeben lässt. (Hier könnte dann ein mal wieder Ausgabe per document.write, und ein mal per DOM interessant sein.)
        (Das darf, wer möchte, als ein <I> um der fachlichen Unterfütterung der Diskussion willen betrachten :-))

        * sofern deren Maschinen Cookies unterstützen?

        MfG ChrisB

        --
        RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
        1. laut PageSpeed, YSlow & Co. blockiert ein Scriptrequest ja das komplette weitere Parsen des DOM (muss er ja quasi auch, solange document.write erlaubt ist) - also käme der Browser während des Ladens und Ausführens des ersten Script noch gar nicht dazu, das zweite Script-Element überhaupt auszuwerten

          Das stimmt im Grunde, aber hier liegt eine Ausnahme vor. Es gibt ein spekulatives Parsing, denn ein SCRIPT hat keinen Einfluss auf ein Folge-SCRIPT. Es kann dessen Herunterladen und Ausführen schwer verhindern. Daher kann der Parser weiterlaufen, um Ressourcen zu finden, die er parallel herunterladen kann (script@src, link@href usw.).

          Aus Sicht des Scripts bleibt alles gleich, es hat nur Zugriff auf den DOM-Baum vor ihm, und dieses »Voraus-Parsen« verhindert auch nicht, dass das Script mit document.write() Inhalte einfügen kann.

          http://hsivonen.iki.fi/speculative-html5-parsing/ (bezieht sich auf Firefox’ HTML5-Parser, aber seit Firefox 3.5 hat auch der alte Parser so ein Feature)
          http://stackoverflow.com/questions/1072774/what-is-speculative-parsing
          https://bugzilla.mozilla.org/show_bug.cgi?id=364315
          https://developer.mozilla.org/en/Optimizing_Your_Pages_for_Speculative_Parsing

          Mathias

      2. Gerade bei Javascript ist das mit der Parallelität ja relativ klar:

        Nein, das ist gar nicht so klar.

        Javascript wird seriell geparst,

        Du meinst ausgeführt, geparst nicht notwendigerweise.

        deshalb werden die Requests - so jedenfalls meine Erwartung - schön nacheinander abgearbeitet. Und zwar das zweite Javascript erst dann, wenn das erste Javascript komplett angefordert und geparst im Speicher des Browsers liegt.

        Nein, das eine folgt nicht notwendig auf das andere. Synchrone Ausführung verhindert nicht paralleles Herunterladen.

        Aus genau diesem Grund der Serialität von JS-Requests wird ja empfohlen, Javascript aus Performancegründen am SeitenENDE einzubinden, wenn schon das meiste im DOM geladen ist und angezeigt wird, während die spezielle Funktionalität noch am Laden ist.

        Jetzt vermischt du einiges. Es sind mehrere Gründe.

        Der Hauptgrund ist: Scripts blocken den HTML-Parser. Deshalb sollte man sie am Dokumentende einbinden, weil sonst das Dokument nicht weitergeparst und dargestellt wird, bis alle Scripte am Dokumentanfang (parallel oder nacheinander) heruntergeladen UND (immer nacheinander) ausgeführt sind. Und Scripte brauchen Zeit zur Ausführung.

        Also kommen diese Faktoren zusammen und verzögern insgesamt den Seitenaufbau:

        • Scripts blocken den HTML-Parser
        • Scripts werden nicht immer parallel heruntergeladen, v.a. bei älteren Browsern
        • Scripts werden immer nacheinander ausgeführt (async-Attribut außen vor)
        • Die Ausführung benötigt einige Zeit

        Die zweite Empfehlung ist, die Anzahl der Javascripte möglichst gering zu halten - aber das Beispiel lässt sich jetzt leider in der Diskussion nicht so drehen, dass man statt zwei Requests nur noch einen hat. ;)

        Diese Empfehlung zielt heutzutage nicht mehr alleine darauf ab, dass Scripte nacheinander heruntergeladen werden. Sie zielt in Zeiten von parallelem Downloaden mehr auf die limitierte Zahl der HTTP-Verbindungen und den HTTP-Overhead ab.

        Interessant für mich wären Browser auf Mac OS, Safari, Chrome, und gerne auch auf Mobilgeräten wie IPhone und Android (wobei das bei letzteren mit der Debug-Konsole wohl schwierig wird).

        Mobile Safari auf iPhone hat eine, auf Android weiß ich gerade nicht, muss ich beizeiten mal nachsehen.

        Mathias

  2. Hallo Sven,

    Was ist das von euch erwartete Verhalten für den Request nach dem zweiten Javascript?

    Gar keines, das Verhalten ist in meinen Augen undefiniert. Die gängige Praxis bei Script-Blöcken (ob's standardisiert ist weiß ich nicht) ist, dass die Scripte hintereinander aufgerufen werden müssen während der DOM-Baum noch aufgebaut wird (d.h. erst das eine, dann erst das andere) - nicht jedoch, dass sie hintereinander geladen werden müssten. Ob das geschieht hängt von vielen Umständen ab: Ob der Browser gleichzeitige Verbindungen zum Server erlaubt oder nicht, ob schon genügend Verbindungen zum Laden anderer Ressourcen verbraten werden oder ob der Browser an Hand des HTML-Quellcodes das zweite Script bereits erkennen kann bevor er fertig damit ist, das erste Script zu holen. Wenn sie jedoch tatsächlich wirklich hintereinander geladen werden, dann wäre meine Erwartungshaltung, dass Deine Variante (a) gilt.

    Spannend wäre es auch, wenn ihr, nachdem ihr eine Vermutung geäußert habt, das mal in eurem/n Lieblingsbrowser/n verifiziert.

    Mit einem extrem simplen Testscript lädt der Firefox unter Linux bei mir die Scripte parallel (sieht man im Firebug ganz gut) und sendet dementsprechend das Cookie nicht beim zweiten Request mit. Wenn ich dagegen in der HTML-Seite nur das erste Script einbette und in der ersten JS-Datei dann per document.write() die zweite einbinde (d.h. die erste Datei verarbeitet sein muss, bevor er weiß, dass er die zweite Laden soll), dann trifft der Fall (a) ein. Deckt sich also mit meinen Erwartungen. (Wobei 2x Fall (a) auch meinen Erwartungen entsprochen hätte, da im ersten Fall ja nicht klar ist, ob der Browser im Source erkennen kann ob er parallel laden kann oder nicht.)

    Darauf, andere Browser durchzutesten, habe ich gerade keine Lust.

    Viele Grüße,
    Christian

    1. Die gängige Praxis bei Script-Blöcken (ob's standardisiert ist weiß ich nicht) ist, dass die Scripte hintereinander aufgerufen werden müssen während der DOM-Baum noch aufgebaut wird (d.h. erst das eine, dann erst das andere)

      Diese De-facto-Regel wird mit HTML5 standardisiert - und gleichzeitig gibts in HTML5 die Wahlmöglichkeit, Scripte auch parallel (also in der Reihenfolge, in der sie übertragen wurden) ausführen zu lassen. Siehe asynchrones JavaScript.

      Das parallele Herunterladen von mehreren Scripten haben neuere Browser eingebaut:
      »Newer browsers (IE8, Firefox 3.5+, Safari 4, Chrome 2+) incorporated this parallel script loading feature« (Quelle)
      Dahin geht auch aus Performancegründen die Entwicklung.

      Mathias

  3. Was ist das von euch erwartete Verhalten für den Request nach dem zweiten Javascript?

    a) Die im ersten Request gesetzten Cookies werden beim zweiten Request schon mitgesendet.

    Ja. denn es interessiert den browser nicht, wer oder was das Cookie gesetzt hat, sondern was in dem Cookie drin steht, und welche Domain dieses Cookie setzt.
    Allenfalls schlägt eine Regel zu, welch es Domain X verbietet Cookies für Domain Y zu setzen.

    Spannend wäre es auch, wenn ihr, nachdem ihr eine Vermutung geäußert habt, das mal in eurem/n Lieblingsbrowser/n verifiziert.

    Ich habe jetzt nicht genau dein Szenario getestst.
    Es ist einfach So:
    Sobald ein Cookie gesetzt wird, dann wird das Cookie bei jedem Folgerequest gesendet, sofern domain/Pfad stimmt.
    Ganz egal, was die Ressource sei, über die der Browser keine Vermutung anstellen soll.

    FF 3.6.8

    mfg Beat

    --
    ><o(((°>           ><o(((°>
       <°)))o><                     ><o(((°>o
    Der Valigator leibt diese Fische
  4. Moin!

    Wann schickt ein Browser ein in einem Request empfangenes Cookie an den Server zurück?

    Ich habe dazu mal einen kleinen Testcase zusammengebaut.

    http://www.selfhtml.org/cookietest/

    Die HTML-Seite ist statisch, das generierte Javascript gibt Auskunft über die empfangenen Cookies. Das spart das aufwendige Checken irgendwelcher HTTP-Header an unzugänglichen Stellen. :)

    - Sven Rautenberg

    1. Hi,

      Ich habe dazu mal einen kleinen Testcase zusammengebaut.

      http://www.selfhtml.org/cookietest/

      Opera 10.60 - erstes Script gibt keine Cookies als vorhanden aus, zweites beide.
      FF 3.6.8, Safari 4.0.3, Chrome 4.1.249.1036, IE 8 - beide Male „nope“.

      (Alle unter Win 7.)

      Und wie gesagt, da waren deine Testausgaben jetzt mit document.write, wie das stattdessen mit DOM-Methoden ausgesehen hätte, hätte mich noch interessiert - aber vermutlich schlicht genauso.

      MfG ChrisB

      --
      RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
      1. Moin!

        Ich habe dazu mal einen kleinen Testcase zusammengebaut.

        http://www.selfhtml.org/cookietest/

        Opera 10.60 - erstes Script gibt keine Cookies als vorhanden aus, zweites beide.
        FF 3.6.8, Safari 4.0.3, Chrome 4.1.249.1036, IE 8 - beide Male „nope“.

        (Alle unter Win 7.)

        Das sind auch meine Ergebnisse - allerdings: Ich habs im Firefox zuerst irgendwie geschafft, dasselbe Ergebnis zu erhalten, wie bei Opera.

        Bzw. war zuallererst nur das Session-Cookie beteiligt, und das wollte im FF so, wie in Opera. Auch das hinzugefügte persistente wollte zuerst (ein oder zwei Requests) genau so übermittelt werden - und seitdem nicht mehr...

        Merkwürdig.

        - Sven Rautenberg

        1. Das sind auch meine Ergebnisse - allerdings: Ich habs im Firefox zuerst irgendwie geschafft, dasselbe Ergebnis zu erhalten, wie bei Opera.

          Das ist schon möglich, weil es nur um wenige Millisekunden handelt. Da kann das Ergebnis mal so und mal so ausfallen.

          Prinpiziell laden alle aktuellen Browser Scripte parallel herunter, deshalb ist nicht garantiert (aber durchaus möglich), dass das zweite Script den Cookie bekommt.

          Dieser Testcase ist eindeutiger, weil ein Script erst nach 4 Sekunden antwortet. Dort bestätigt sich auch, dass Opera 10.6 Scripte nie parallel herunterlädt.

          Vgl. auch Browserscope Network Tests.

          Mathias

    2. http://www.selfhtml.org/cookietest/

      Anhand dieser Wasserfall-Diagramme ist das Ergebnis vorhersagbar: Nur im IE 9 ist es überhaupt möglich, dass der zweite Request den Cookie enthalten kann, weil die anderen Browser die Script-Requests nahezu gleichzeitig starten, jedenfalls wird der zweite Request weit vor dem Empfangen der Antwort des ersten gestartet.

      Für den IE 8:
      http://www.webpagetest.org/result/100804_2B19/1/details/
      So richtig schlau werde ich aus dem Diagramm nicht. Die Requests werden parallel gestartet, aber er scheint beim zweiten irgendwie zu warten. In meinem IE 8 bekommt das zweite Script jedenfalls nicht den Cookie, also wird parallel heruntergeladen.
      Vgl. auch http://stevesouders.com/cuzillion/?ex=3&title=IE8+Parallel+Script+Loading

      Laut http://www.browserscope.org/network/tests/scripts-block-scripts kann der IE9 eigentlich auch parallel downloaden - zumindest prinzipiell. Bei deinen Beispielscripten fehlt wohl eine nötige Verzögerung (z.B. mit sleep()), sodass das Resultat eindeutig wird.

      Mathias

    3. Tach auch.

      Moin!

      Wann schickt ein Browser ein in einem Request empfangenes Cookie an den Server zurück?
      http://www.selfhtml.org/cookietest/

      Fennec (Firefox Mobile auf N900/Maemo):
      Request Nummer 1: Session-Cookie war nicht dabei
      Persistent-Cookie war nicht dabei
      Request Nummer 2: Session-Cookie war nicht dabei
      Persistent-Cookie war nicht dabei

      N900/Maemo: eingebauter Browser (kA, welche Engine)
      Request Nummer 1: Session-Cookie war nicht dabei
      Persistent-Cookie war nicht dabei
      Request Nummer 2: Session-Cookie war nicht dabei
      Persistent-Cookie war nicht dabei

      Firefox 3.6.3/Linux
      Request Nummer 1: Session-Cookie war nicht dabei
      Persistent-Cookie war nicht dabei
      Request Nummer 2: Session-Cookie war dabei und enthielt "Datum: 2010-08-05 11:23:10"
      Persistent-Cookie war dabei und enthielt "Datum: 2010-08-05 11:23:10"

      Konqueror 4.4.2/Linux
      Request Nummer 1: Session-Cookie war nicht dabei
      Persistent-Cookie war nicht dabei
      Request Nummer 2: Session-Cookie war dabei und enthielt "Datum: 2010-08-05 11:24:38"
      Persistent-Cookie war dabei und enthielt "Datum: 2010-08-05 11:24:38"

      Firefox 3.6.8/Mac OS X
      Request Nummer 1: Session-Cookie war nicht dabei
      Persistent-Cookie war nicht dabei
      Request Nummer 2: Session-Cookie war nicht dabei
      Persistent-Cookie war nicht dabei

      Safari 4.0.5/Mac OS X
      Request Nummer 1: Session-Cookie war nicht dabei
      Persistent-Cookie war nicht dabei
      Request Nummer 2: Session-Cookie war nicht dabei
      Persistent-Cookie war nicht dabei

      Gruß,
      Matti

    4. Tach,

      Die HTML-Seite ist statisch, das generierte Javascript gibt Auskunft über die empfangenen Cookies. Das spart das aufwendige Checken irgendwelcher HTTP-Header an unzugänglichen Stellen. :)

      Android 2.1: Eingebauter Browser und Dolphin haben beide keinen der 4 Cookies.

      mfg
      Woodfighter

    5. moin Sven,

      .. Das spart das aufwendige Checken irgendwelcher HTTP-Header an unzugänglichen Stellen. :)

      Das Checken der Header gehört zum Handwerk eines Programmierers genauso wie das Schleifen eines Rasiermessers zum Handwerk eines Barbiers gehört. Da gibt es nichts, was den Zugang verwehrt ;-)

      Viele Grüße,
      Horst Wate

      --
      Erfolgsrezept php und mysql? Keins von Beiden!