Nous avons des sessions ASP.NET de cookieless (inproc), de sorte que l'URL contient l'identifiant de session, à savoir S (dfasfdafasdfasfa)Comment IIS7 détermine-t-il la même session dans un scénario sans cookie?
Nous avons aussi plusieurs clients en passant par des serveurs proxy où il apparaît comme notre serveur Web ne reconnaît pas la ID de session et sans les données de session, ils ne peuvent pas continuer. J'ai testé nos sites sur des proxies ouverts et ils fonctionnent bien. Mais il se passe quelque chose avec ce serveur proxy client particulier qui provoque ce comportement.
J'ai examiné les captures de paquets pour les cas de réussite et d'échec (fournis par le client) et le HTML brut transmis, y compris les en-têtes, est le même. Le serveur proxy ne semble pas mettre en cache les URL, car l'ID de session correct est en train de disparaître. Donc, je pense que IIS7 utilise quelque chose en plus de l'identifiant de session dans l'URL pour déterminer un client unique. Peut-être quelque chose au niveau TCP/IP? Plutôt que juste niveau App (http). Est-ce sur la bonne voie? Est-ce que quelqu'un connaît la réponse à cela?
Malheureusement, sans être en mesure de recréer ce scénario localement, je me bats le cerveau.
Je ne crois pas que ce soit un problème de recyclage d'applications, car le site fonctionne comme prévu lorsque vous n'utilisez pas de serveur proxy ou lorsque vous l'exécutez via quelques-uns des proxys ouverts que j'ai trouvés sur le Web. Ce n'est que lorsque notre client a son proxy d'entreprise au milieu. –
Que voyez-vous lors de la connexion de l'URL de la requête avec SessionId? – Nariman
Bien que l'URL que nous enregistrons ne contienne pas l'ID de session au moment où il descend au moteur ASP.NET, car le filtre ISAPI le supprime. Mais l'identifiant de session que nous enregistrons correspond à l'URL que nous voyons dans les journaux de trace du client –