Theory
Web आपको Instantly भूल जाता है
Web के बारे में एक awkward truth यहाँ है: HTTP stateless है। हर request पूरी तरह अलग खड़ा है; server naturally पिछले वाले के बारे में कुछ याद नहीं रखता। तो एक student FestConnect में login करने और अगले page पर click करने के बाद, server को, default से, कोई memory नहीं कि ये बिल्कुल logged in हैं।
यह stand नहीं कर सकता, apps को याद रखना पड़ता है आप कौन हैं, आपके cart में क्या है, आपने क्या picked। Requests के across data remember करने की techniques के set को state management कहा जाता है, और यह lesson main ones survey करता है।
Theory
State रखने के लिए दो Places
State दो places में रह सकता है, और यह split पूरे topic की key है।
Client-side state visitor के browser या URL में stored है, और हर request के साथ back और forth travel करता है: cookies (छोटा key-value data जो browser store करता है और re-send करता है), query string (एक ? के बाद URL में values), hidden fields, और view state (एक page की अपनी control values, postbacks के across preserved)।
Server-side state server पर stored है और browser इसे बस reference करता है: session state (एक particular user के लिए data) और application state (सारे users से shared data)।
At a glance
| Technique | कहाँ Stored | Reach और Typical Use |
|---|---|---|
| Cookie | Browser (client) | Visits के across छोटा per-user data (जैसे 'remember me') |
| Query String | URL (client) | Pages के बीच एक value pass कीजिए (जैसे ?eventId=12); visible, secrets के लिए नहीं |
| View State | Page खुद (client) | एक page की control values को इसके own postbacks के across preserve कीजिए |
| Session | Server, per user | कौन logged in है, एक cart; user के session तक लास्ट करता है |
| Application | Server, shared | हर किसी के लिए common data (जैसे एक visitor counter) |
Formula
Client-Side बनाम Server-Side State
Client-Side (cookies, query string, view state): data browser या URL में ride करता है। यह server को कोई memory cost नहीं करता, पर यह user को visible या reachable है, तो वहाँ कभी secrets या ऐसी चीज़ें मत डालिए जिनके साथ user tamper नहीं करना चाहिए।
Server-Side (session, application): data safely server पर रहता है; browser सिर्फ़ एक छोटा id hold करता है जो इसे point करता है। यह ज़्यादा secure है और ज़्यादा hold कर सकता है, पर server memory इस्तेमाल करता है। Sensitivity और size से choose कीजिए: छोटा और harmless client-side जा सकता है; private या important server-side belong करता है।
Practical
Session (per user) and a cookie
// SERVER-SIDE: remember the logged-in student for this user's session
Session["studentName"] = txtName.Text;
// ...on a later page, read it back:
string who = Session["studentName"] as string;
// CLIENT-SIDE: store a small preference in a cookie for 30 days
var prefs = new HttpCookie("theme", "dark");
prefs.Expires = DateTime.Now.AddDays(30);
Response.Cookies.Add(prefs);
// Read a value passed in the URL (?eventId=12)
string eventId = Request.QueryString["eventId"];Quiz
आपको FestConnect को यह याद रखना पड़ता है कि pages के बीच move करते हुए कौन सा student logged in है, server पर securely kept। कौन सी technique सबसे अच्छी fit होती है?
- Query string, हर URL में student का name डालते हुए
- Session state, जो server पर उनके session की duration के लिए per-user data store करता है
- Student का password hold करती एक cookie
- Application state, क्योंकि यह सारे users से shared है
Show the answer
Session state, जो server पर उनके session की duration के लिए per-user data store करता है
Session state ONE particular user के लिए data SERVER पर store करता है और उनके session की length के लिए इनकी requests के across persist करता है, जो 'कौन logged in है' के लिए exactly right है। Option A poor है: query string data को URL में डालता है, जो visible है, easily edited है, और हर link को clutter करता है, identity के लिए wrong। Option C dangerous है: कभी एक cookie में password store मत कीजिए; cookies browser में रहती हैं और पढ़ी या चुराई जा सकती हैं। Option D wrong है: application state सारे users से SHARED है, तो यह एक specific user की identity hold नहीं कर सकता, यह हर किसी के लिए same value होगी। Per-user और private -> server-side session।
Think first
Cookie या Session: आप कैसे Choose करते हैं?
एक cookie और session दोनों per user कुछ याद रख सकते हैं। हर एक के लिए आप कब reach करते हैं? फिर tap कीजिए।
Show the answer
यह choose कीजिए data कहाँ रहना चाहिए और यह कितना sensitive है इससे। एक COOKIE data को browser में store करता है, तो यह survive करता है user के site close करके बाद में वापस आने के बाद भी (जब तक यह expire न हो), और यह server को कोई memory cost नहीं करता, पर user इसे देख और edit कर सकता है, तो यह 'my theme remember कीजिए' या 'remember me' जैसी छोटी, non-secret preferences के लिए suit करता है। SESSION data को SERVER पर store करता है, उस user से keyed; browser सिर्फ़ एक tiny session id hold करता है, तो real data private और tamper-resistant है, और यह बड़े, richer objects hold कर सकता है, पर server memory इस्तेमाल करता है और normally सिर्फ़ session timeout या user के जाने तक लास्ट करता है। Rule of thumb: harmless, छोटा, और visits के across persist होना चाहिए -> cookie; private, important, या बड़ा, और सिर्फ़ इस visit के लिए -> session। अक्सर ये साथ काम करते हैं: एक session id खुद एक cookie में carried होता है। Mechanism को data की sensitivity और lifetime से match कीजिए।
Summary
Key takeaways
- HTTP stateless है: हर request independent है, तो apps requests के across data remember करने के लिए state management इस्तेमाल करते हैं।
- Client-side state browser या URL में ride करता है: cookies (छोटा persistent data), query string (URL में values), view state (postbacks के across page की control values)।
- Server-side state server पर रहता है: session (per user) और application (सारे users से shared)।
- Client-side कोई server memory cost नहीं करता पर visible या editable है; वहाँ कभी secrets मत डालिए।
- Server-side private है और ज़्यादा hold कर सकता है, server memory की cost पर।
- Per-user identity के लिए session इस्तेमाल कीजिए, छोटी persistent preferences के लिए एक cookie, सिर्फ़ non-secret values के लिए query string।
- Memory hook: cookies और query string client पर रहते हैं; session और application server पर रहते हैं।