dans l'excellllent livre de Smacchia sur C#, un court paragraphe est consacré à la gestion des états avec ASP.NET.
Il y a d'après l'auteur deux catégories de techniques utilisables avec ASP.NET:
- celles qui "communiquent l'état au client" : cookie, View State, GET et Query-String, controls cachés.
- celles qui garde l'état seulement du côté du serveur: Application State, Session state, utilisation d'une base de données.
Ce que je ne comprends pas, dans la deuxième catégorie, c'est comment le serveur identifie une connexion rentrante, si "l'état est
gardé seulement du côté du serveur" ???? Ceci dit, Smacchia dit bien que l'identificateur qui identifie la session, dans le cadre du
"Session State" est encapsulé dans chaque requête, soir dans l'URL (Query string), soit dans un cookie.
Donc fondamentalement, l'état est aussi transmis au client... Et finalement la distinction entre les deux techniques ne ma parait
pas franche.
Sur ce sujet, une autre question: lorsque l'identification des clients est "Windows", le token contenant l'ID Windows du client est
transmis comment au serveur lors de chaque requête ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Zazar
Bonjour,
Ce que je ne comprends pas, dans la deuxième catégorie, c'est comment le
serveur identifie une connexion rentrante, si "l'état est
gardé seulement du côté du serveur" ???? Ceci dit, Smacchia dit bien que
l'identificateur qui identifie la session, dans le cadre du
"Session State" est encapsulé dans chaque requête, soir dans l'URL (Query
string), soit dans un cookie.
Donc fondamentalement, l'état est aussi transmis au client... Et
finalement la distinction entre les deux techniques ne ma parait
pas franche.
Dans le cas d'un état stocké dans l'ApplicationState, rien n'est renvoyé au client. Cet état est partagé entre tous les clients. Dans le cas d'une session, quelques octets sont envoyés au client afin de pouvoir identifier la session stockée du coté serveur. Les données ne transitent pas par le réseau : gain de bande passante si les données sont importantes, et intégrité des données garantie.
-- Zazar
Bonjour,
Ce que je ne comprends pas, dans la deuxième catégorie, c'est comment le
serveur identifie une connexion rentrante, si "l'état est
gardé seulement du côté du serveur" ???? Ceci dit, Smacchia dit bien que
l'identificateur qui identifie la session, dans le cadre du
"Session State" est encapsulé dans chaque requête, soir dans l'URL (Query
string), soit dans un cookie.
Donc fondamentalement, l'état est aussi transmis au client... Et
finalement la distinction entre les deux techniques ne ma parait
pas franche.
Dans le cas d'un état stocké dans l'ApplicationState, rien n'est renvoyé au
client. Cet état est partagé entre tous les clients.
Dans le cas d'une session, quelques octets sont envoyés au client afin de
pouvoir identifier la session stockée du coté serveur. Les données ne
transitent pas par le réseau : gain de bande passante si les données sont
importantes, et intégrité des données garantie.
Ce que je ne comprends pas, dans la deuxième catégorie, c'est comment le
serveur identifie une connexion rentrante, si "l'état est
gardé seulement du côté du serveur" ???? Ceci dit, Smacchia dit bien que
l'identificateur qui identifie la session, dans le cadre du
"Session State" est encapsulé dans chaque requête, soir dans l'URL (Query
string), soit dans un cookie.
Donc fondamentalement, l'état est aussi transmis au client... Et
finalement la distinction entre les deux techniques ne ma parait
pas franche.
Dans le cas d'un état stocké dans l'ApplicationState, rien n'est renvoyé au client. Cet état est partagé entre tous les clients. Dans le cas d'une session, quelques octets sont envoyés au client afin de pouvoir identifier la session stockée du coté serveur. Les données ne transitent pas par le réseau : gain de bande passante si les données sont importantes, et intégrité des données garantie.
-- Zazar
Oriane
"Zazar" a écrit dans le message de news: | Dans le cas d'une session, quelques octets sont envoyés au client afin de | pouvoir identifier la session stockée du coté serveur. Les données ne | transitent pas par le réseau : gain de bande passante si les données sont | importantes, et intégrité des données garantie. Je répète donc ma question: comment le serveur identifie-t-il une connexion entrante si rien n'est envoyé par me client ?
Oriane
"Zazar" <DILAVNI.nicolas.prats@iie.cnam.fr.INVALID> a écrit dans le message de news:egfe6MGYEHA.2364@TK2MSFTNGP12.phx.gbl...
| Dans le cas d'une session, quelques octets sont envoyés au client afin de
| pouvoir identifier la session stockée du coté serveur. Les données ne
| transitent pas par le réseau : gain de bande passante si les données sont
| importantes, et intégrité des données garantie.
Je répète donc ma question: comment le serveur identifie-t-il une connexion entrante si rien n'est envoyé par me client ?
"Zazar" a écrit dans le message de news: | Dans le cas d'une session, quelques octets sont envoyés au client afin de | pouvoir identifier la session stockée du coté serveur. Les données ne | transitent pas par le réseau : gain de bande passante si les données sont | importantes, et intégrité des données garantie. Je répète donc ma question: comment le serveur identifie-t-il une connexion entrante si rien n'est envoyé par me client ?
Oriane
Zazar
Bonsoir,
| Dans le cas d'une session, quelques octets sont envoyés au client afin
de
| pouvoir identifier la session stockée du coté serveur. Les données ne | transitent pas par le réseau : gain de bande passante si les données
sont
| importantes, et intégrité des données garantie. Je répète donc ma question: comment le serveur identifie-t-il une
connexion entrante si rien n'est envoyé par me client ?
"quelques octets sont envoyés au client afin de pouvoir identifier la session stockée du coté serveur" -> ça signifie bien que quelque chose est envoyé au client.
-- Zazar
Bonsoir,
| Dans le cas d'une session, quelques octets sont envoyés au client afin
de
| pouvoir identifier la session stockée du coté serveur. Les données ne
| transitent pas par le réseau : gain de bande passante si les données
sont
| importantes, et intégrité des données garantie.
Je répète donc ma question: comment le serveur identifie-t-il une
connexion entrante si rien n'est envoyé par me client ?
"quelques octets sont envoyés au client afin de pouvoir identifier la
session stockée du coté serveur" -> ça signifie bien que quelque chose est
envoyé au client.
| Dans le cas d'une session, quelques octets sont envoyés au client afin
de
| pouvoir identifier la session stockée du coté serveur. Les données ne | transitent pas par le réseau : gain de bande passante si les données
sont
| importantes, et intégrité des données garantie. Je répète donc ma question: comment le serveur identifie-t-il une
connexion entrante si rien n'est envoyé par me client ?
"quelques octets sont envoyés au client afin de pouvoir identifier la session stockée du coté serveur" -> ça signifie bien que quelque chose est envoyé au client.
-- Zazar
Oriane
"Zazar" a écrit dans le message de news:e% | Bonsoir, | | > | Dans le cas d'une session, quelques octets sont envoyés au client afin | de | > | pouvoir identifier la session stockée du coté serveur. Les données ne | > | transitent pas par le réseau : gain de bande passante si les données | sont | > | importantes, et intégrité des données garantie. | > Je répète donc ma question: comment le serveur identifie-t-il une | connexion entrante si rien n'est envoyé par me client ? | | "quelques octets sont envoyés au client afin de pouvoir identifier la | session stockée du coté serveur" -> ça signifie bien que quelque chose est | envoyé au client. J'entends bien mais je n'ai pas écrit (avec une faute d'ailleurs) "au client" mais "par le client". Comment le serveur identifie -t- il les connexions entrantes ? Soir le client a un cookie, soit il passe des paramètres dans une query, soi t dans une variable....mais il faut bien qu'il envoie qqchose... | | -- | Zazar Oriane
"Zazar" <DILAVNI.nicolas.prats@iie.cnam.fr.INVALID> a écrit dans le message de news:e%2369iWsYEHA.3516@TK2MSFTNGP09.phx.gbl...
| Bonsoir,
|
| > | Dans le cas d'une session, quelques octets sont envoyés au client afin
| de
| > | pouvoir identifier la session stockée du coté serveur. Les données ne
| > | transitent pas par le réseau : gain de bande passante si les données
| sont
| > | importantes, et intégrité des données garantie.
| > Je répète donc ma question: comment le serveur identifie-t-il une
| connexion entrante si rien n'est envoyé par me client ?
|
| "quelques octets sont envoyés au client afin de pouvoir identifier la
| session stockée du coté serveur" -> ça signifie bien que quelque chose est
| envoyé au client.
J'entends bien mais je n'ai pas écrit (avec une faute d'ailleurs) "au client" mais "par le client".
Comment le serveur identifie -t- il les connexions entrantes ?
Soir le client a un cookie, soit il passe des paramètres dans une query, soi t dans une variable....mais il faut bien qu'il envoie
qqchose...
|
| --
| Zazar
Oriane
"Zazar" a écrit dans le message de news:e% | Bonsoir, | | > | Dans le cas d'une session, quelques octets sont envoyés au client afin | de | > | pouvoir identifier la session stockée du coté serveur. Les données ne | > | transitent pas par le réseau : gain de bande passante si les données | sont | > | importantes, et intégrité des données garantie. | > Je répète donc ma question: comment le serveur identifie-t-il une | connexion entrante si rien n'est envoyé par me client ? | | "quelques octets sont envoyés au client afin de pouvoir identifier la | session stockée du coté serveur" -> ça signifie bien que quelque chose est | envoyé au client. J'entends bien mais je n'ai pas écrit (avec une faute d'ailleurs) "au client" mais "par le client". Comment le serveur identifie -t- il les connexions entrantes ? Soir le client a un cookie, soit il passe des paramètres dans une query, soi t dans une variable....mais il faut bien qu'il envoie qqchose... | | -- | Zazar Oriane
Patrice
Oui, la session est maintenue par un cookie dont la gestion est "transparente" pour le développeur.
Patrice
--
"Oriane" a écrit dans le message de news:ccdnf9$tq5$
"Zazar" a écrit dans le
message de news:e%
| Bonsoir, | | > | Dans le cas d'une session, quelques octets sont envoyés au client
afin
| de | > | pouvoir identifier la session stockée du coté serveur. Les données
ne
| > | transitent pas par le réseau : gain de bande passante si les données | sont | > | importantes, et intégrité des données garantie. | > Je répète donc ma question: comment le serveur identifie-t-il une | connexion entrante si rien n'est envoyé par me client ? | | "quelques octets sont envoyés au client afin de pouvoir identifier la | session stockée du coté serveur" -> ça signifie bien que quelque chose
est
| envoyé au client. J'entends bien mais je n'ai pas écrit (avec une faute d'ailleurs) "au
client" mais "par le client".
Comment le serveur identifie -t- il les connexions
entrantes ?
Soir le client a un cookie, soit il passe des paramètres dans une query,
soi t dans une variable....mais il faut bien qu'il envoie
qqchose... | | -- | Zazar Oriane
Oui, la session est maintenue par un cookie dont la gestion est
"transparente" pour le développeur.
Patrice
--
"Oriane" <Oriane@guermantes.com> a écrit dans le message de
news:ccdnf9$tq5$1@yucatan.franconews.org...
"Zazar" <DILAVNI.nicolas.prats@iie.cnam.fr.INVALID> a écrit dans le
message de news:e%2369iWsYEHA.3516@TK2MSFTNGP09.phx.gbl...
| Bonsoir,
|
| > | Dans le cas d'une session, quelques octets sont envoyés au client
afin
| de
| > | pouvoir identifier la session stockée du coté serveur. Les données
ne
| > | transitent pas par le réseau : gain de bande passante si les données
| sont
| > | importantes, et intégrité des données garantie.
| > Je répète donc ma question: comment le serveur identifie-t-il une
| connexion entrante si rien n'est envoyé par me client ?
|
| "quelques octets sont envoyés au client afin de pouvoir identifier la
| session stockée du coté serveur" -> ça signifie bien que quelque chose
est
| envoyé au client.
J'entends bien mais je n'ai pas écrit (avec une faute d'ailleurs) "au
client" mais "par le client".
Comment le serveur identifie -t- il les connexions
entrantes ?
Soir le client a un cookie, soit il passe des paramètres dans une query,
soi t dans une variable....mais il faut bien qu'il envoie
Oui, la session est maintenue par un cookie dont la gestion est "transparente" pour le développeur.
Patrice
--
"Oriane" a écrit dans le message de news:ccdnf9$tq5$
"Zazar" a écrit dans le
message de news:e%
| Bonsoir, | | > | Dans le cas d'une session, quelques octets sont envoyés au client
afin
| de | > | pouvoir identifier la session stockée du coté serveur. Les données
ne
| > | transitent pas par le réseau : gain de bande passante si les données | sont | > | importantes, et intégrité des données garantie. | > Je répète donc ma question: comment le serveur identifie-t-il une | connexion entrante si rien n'est envoyé par me client ? | | "quelques octets sont envoyés au client afin de pouvoir identifier la | session stockée du coté serveur" -> ça signifie bien que quelque chose
est
| envoyé au client. J'entends bien mais je n'ai pas écrit (avec une faute d'ailleurs) "au
client" mais "par le client".
Comment le serveur identifie -t- il les connexions
entrantes ?
Soir le client a un cookie, soit il passe des paramètres dans une query,
soi t dans une variable....mais il faut bien qu'il envoie
qqchose... | | -- | Zazar Oriane
Oriane
"Patrice" a écrit dans le message de news: | Oui, la session est maintenue par un cookie dont la gestion est | "transparente" pour le développeur. | | Patrice Négatif. Le cas "Session State" est justement un cas où l'on se passe de cookie.
"Patrice" <nobody@nowhere.com> a écrit dans le message de news:OqH5YuzYEHA.3988@tk2msftngp13.phx.gbl...
| Oui, la session est maintenue par un cookie dont la gestion est
| "transparente" pour le développeur.
|
| Patrice
Négatif. Le cas "Session State" est justement un cas où l'on se passe de cookie.
"Patrice" a écrit dans le message de news: | Oui, la session est maintenue par un cookie dont la gestion est | "transparente" pour le développeur. | | Patrice Négatif. Le cas "Session State" est justement un cas où l'on se passe de cookie.
Zazar
Bonjour,
J'entends bien mais je n'ai pas écrit (avec une faute d'ailleurs) "au
client" mais "par le client".
Ha, désolé, j'avais mal compris votre question.
Comment le serveur identifie -t- il les connexions
entrantes ?
Les octets identifiant la session sont transmis au client soit sous forme de cookie, soit via un paramètre dans l'url en fonction de la configuration de l'application Web. Dans le premier cas, le client renvoie donc le cookie, dans le second cas, c'est en décodant l'url de la page demandée par le client qu'on peut retrouver l'identifiant de session.
-- Zazar
Bonjour,
J'entends bien mais je n'ai pas écrit (avec une faute d'ailleurs) "au
client" mais "par le client".
Ha, désolé, j'avais mal compris votre question.
Comment le serveur identifie -t- il les connexions
entrantes ?
Les octets identifiant la session sont transmis au client soit sous forme de
cookie, soit via un paramètre dans l'url en fonction de la configuration de
l'application Web. Dans le premier cas, le client renvoie donc le cookie,
dans le second cas, c'est en décodant l'url de la page demandée par le
client qu'on peut retrouver l'identifiant de session.
J'entends bien mais je n'ai pas écrit (avec une faute d'ailleurs) "au
client" mais "par le client".
Ha, désolé, j'avais mal compris votre question.
Comment le serveur identifie -t- il les connexions
entrantes ?
Les octets identifiant la session sont transmis au client soit sous forme de cookie, soit via un paramètre dans l'url en fonction de la configuration de l'application Web. Dans le premier cas, le client renvoie donc le cookie, dans le second cas, c'est en décodant l'url de la page demandée par le client qu'on peut retrouver l'identifiant de session.
-- Zazar
Patrice
En fait même dans le cas "SessionState", il faut quand même faire appel à la notion de session. Cette notion de session est généralement gérée par un cookie (qui contient un simple identifiant de session) dont la gestion est **transparente** pour le développeur.
Ton bouquin s'attache je pense à ce que **fait** le développeur. Les variables de session sont bien stockées uniquement sur le serveur. Néanmoins, l'infrastrucure ASP/ASP.NET utilise tout de même un cookie (dont le développeur n'a pas à s'occuper ou même à connaître l'existance) pour pouvoir "identifier" la session et exposer côté serveur les variables de session qui correspondent à la "session" pour laquelle est exécutée la requête HTTP courante...
Pour ASP.NET, cet aspect est configurable et il est possible de se passer totalement de cookie (l'ID de session est alors intégré dans l'URL).
Cf par exemple : http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/cpgenref/html/gngrfSessionstateSection.asp
--
"Oriane" a écrit dans le message de news:ccdssk$381$
"Patrice" a écrit dans le message de
news:
| Oui, la session est maintenue par un cookie dont la gestion est | "transparente" pour le développeur. | | Patrice Négatif. Le cas "Session State" est justement un cas où l'on se passe de
cookie.
En fait même dans le cas "SessionState", il faut quand même faire appel à la
notion de session. Cette notion de session est généralement gérée par un
cookie (qui contient un simple identifiant de session) dont la gestion est
**transparente** pour le développeur.
Ton bouquin s'attache je pense à ce que **fait** le développeur. Les
variables de session sont bien stockées uniquement sur le serveur.
Néanmoins, l'infrastrucure ASP/ASP.NET utilise tout de même un cookie (dont
le développeur n'a pas à s'occuper ou même à connaître l'existance) pour
pouvoir "identifier" la session et exposer côté serveur les variables de
session qui correspondent à la "session" pour laquelle est exécutée la
requête HTTP courante...
Pour ASP.NET, cet aspect est configurable et il est possible de se passer
totalement de cookie (l'ID de session est alors intégré dans l'URL).
Cf par exemple :
http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/cpgenref/html/gngrfSessionstateSection.asp
--
"Oriane" <Oriane@guermantes.com> a écrit dans le message de
news:ccdssk$381$1@yucatan.franconews.org...
"Patrice" <nobody@nowhere.com> a écrit dans le message de
news:OqH5YuzYEHA.3988@tk2msftngp13.phx.gbl...
| Oui, la session est maintenue par un cookie dont la gestion est
| "transparente" pour le développeur.
|
| Patrice
Négatif. Le cas "Session State" est justement un cas où l'on se passe de
En fait même dans le cas "SessionState", il faut quand même faire appel à la notion de session. Cette notion de session est généralement gérée par un cookie (qui contient un simple identifiant de session) dont la gestion est **transparente** pour le développeur.
Ton bouquin s'attache je pense à ce que **fait** le développeur. Les variables de session sont bien stockées uniquement sur le serveur. Néanmoins, l'infrastrucure ASP/ASP.NET utilise tout de même un cookie (dont le développeur n'a pas à s'occuper ou même à connaître l'existance) pour pouvoir "identifier" la session et exposer côté serveur les variables de session qui correspondent à la "session" pour laquelle est exécutée la requête HTTP courante...
Pour ASP.NET, cet aspect est configurable et il est possible de se passer totalement de cookie (l'ID de session est alors intégré dans l'URL).
Cf par exemple : http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/cpgenref/html/gngrfSessionstateSection.asp
--
"Oriane" a écrit dans le message de news:ccdssk$381$
"Patrice" a écrit dans le message de
news:
| Oui, la session est maintenue par un cookie dont la gestion est | "transparente" pour le développeur. | | Patrice Négatif. Le cas "Session State" est justement un cas où l'on se passe de
cookie.
Oriane
Réponse claire.
Merci beaucoup.
"Patrice" a écrit dans le message de news: | En fait même dans le cas "SessionState", il faut quand même faire appel à la | notion de session. Cette notion de session est généralement gérée par un | cookie (qui contient un simple identifiant de session) dont la gestion est | **transparente** pour le développeur. | [...]
Réponse claire.
Merci beaucoup.
"Patrice" <nobody@nowhere.com> a écrit dans le message de news:uGUaf40YEHA.2408@tk2msftngp13.phx.gbl...
| En fait même dans le cas "SessionState", il faut quand même faire appel à la
| notion de session. Cette notion de session est généralement gérée par un
| cookie (qui contient un simple identifiant de session) dont la gestion est
| **transparente** pour le développeur.
|
[...]
"Patrice" a écrit dans le message de news: | En fait même dans le cas "SessionState", il faut quand même faire appel à la | notion de session. Cette notion de session est généralement gérée par un | cookie (qui contient un simple identifiant de session) dont la gestion est | **transparente** pour le développeur. | [...]
