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