Simplicity The cookie is a lightweight, text-based structure with simple key-value pairs.

Data persistence Although the durability of the cookie on a client computer is subject to cookie
expiration processes on the client and user intervention, cookies are generally the most durable form of data
persistence on the client.
Disadvantages
Size limitations !ost browsers place a "#$%-byte limit on the si&e of a cookie, although support for '($)-
byte cookies is becoming more common in newer browser and client-device versions.
User-configured refusal *ome users disable their browser or client device+s ability to receive cookies,
thereby limiting this functionality.
Potential security risks ,ookies are subject to tampering. -sers can manipulate cookies on their
computer, which can potentially cause a security risk or cause the application that is dependent on the
cookie to fail. Also, although cookies are only accessible by the domain that sent them to the client, hackers
have historically found ways to access cookies from other domains on a user+s computer. .ou can manually
encrypt and decrypt cookies, but it re/uires extra coding and can affect application performance because of
the time that is re/uired for encryption and decryption. 0or more information

1uery *trings - 1uery strings store values in the -23 that are visible to the user. -se /uery strings when you want a
user to be able to e-mail or instant message state data with a -23.
Advantages
No server resources are required The /uery string is contained in the 4TT5 re/uest for a specific -23.
Widespread support Almost all browsers and client devices support using /uery strings to pass values.
Simple implementation A*5.67T provides full support for the /uery-string method, including methods
of reading /uery strings using the 5arams property of the 4ttp2e/uest object.
Disadvantages
Potential security risks The information in the /uery string is directly visible to the user via the browser+s
user interface. A user can bookmark the -23 or send the -23 to other users, thereby passing the
information in the /uery string along with it. 8f you are concerned about any sensitive data in the /uery
string, consider using hidden fields in a form that uses 59*T instead of using /uery strings. 0or more
information, see A*5.67T :eb Application *ecurity and ;asic *ecurity 5ractices for :eb Applications.
Limited capacity *ome browsers and client devices impose a )#'<-character limit on the length of -23s.
***! maintains state information on the server. 4owever it can use costly resources on the server.
Application *tate - Application *tate information is available to all pages regardless of !"ic" user requests a
page. Data that does not change from one user to another is stored in this.Application state is stored in a key=value
dictionary that is created during each re/uest to a specific -23.
Advantages
Simple implementation Application state is easy to use, familiar to A*5 developers, and consistent with
other .67T 0ramework classes.
#pplication scope ;ecause application state is accessible to all pages in an application, storing
information in application state can mean keeping only a single copy of the information >for instance, as
opposed to keeping copies of information in session state or in individual pages?.
Disadvantages
#pplication scope The scope of application state can also be a disadvantage. @ariables stored in
application state are global only to the particular process the application is running in, and each application
process can have different values. Therefore, you cannot rely on application state to store uni/ue values or
update global counters in :eb-garden and :eb-farm server configurations.
Limited durability of data ;ecause global data that is stored in application state is volatile, it will be lost
if the :eb server process containing it is destroyed, such as from a server crash, upgrade, or shutdown.
$esource requirements Application state re/uires server memory, which can affect the performance of
the server as well as the scalability of the application.
*ession *tate A *ession *tate information is available to all pages opened by a user during a single visit. 8t is specific
to single user session. 8f different users are using your application, each user session will have a different session
state. *ession variables are stored on the server. :hat is stored in a cookie is the session id. 8t is used to restore the
session variables on the server when client+s post back arrives.
:hen a session is initiated on first re/uest, the server issues a uni/ue session 8D to the user. To persist the session
8D, store it in an in-memory cookie >which is the default?, or embed it within the re/uest -23 after the application
name >cookie less session?.
7ach active A*5.67T session is identified and tracked using a ()#-bit *ession8D string containing only the A*,88
characters that are allowed in -23s. *ession8D values are generated using an algorithm that guarantees uni/ueness
so that sessions do not collide, and randomness so that a malicious user cannot use a new *ession8D to calculate the
*ession8D of an existing session.
The *ession8D strings are communicated across client-server re/uests either by means of an 4TT5 cookie>client
side? or a modified -23 with the *ession8D string embedded>cookie less?.
Advantages
Simple implementation The session-state facility is easy to use, familiar to A*5 developers, and
consistent with other .67T 0ramework classes.
Session-specific events *ession management events can be raised and used by your application.
Data persistence Data placed in session-state variables can be preserved through 8nternet 8nformation
*ervices >88*? restarts and worker-process restarts without losing session data because the data is stored in
another process space. Additionally, session-state data can be persisted across multiple processes, such as in
a :eb farm or a :eb garden.
Platform scalability *ession state can be used in both multi-computer and multi-process configurations,
therefore optimi&ing scalability scenarios.
%ookieless support *ession state works with browsers that do not support 4TT5 cookies, although
session state is most commonly used with cookies to provide user identification facilities to a :eb
application. -sing session state without cookies, however, re/uires that the session identifier be placed in
the /uery string, which is subject to the security issues stated in the /uery string section of this topic. 0or
more information about using session state without cookies, see Administering A*5.67T :eb *ites.
&'tensibility .ou can customi&e and extend session state by writing your own session-state provider.
*ession state data can then be stored in a custom data format in a variety of data storage mechanisms, such
as a database, an B!3 file, or even to a :eb service. 0or more information, see 8mplementing a *ession-
*tate *tore 5rovider.
Disadvantages
Performance considerations *ession-state variables stay in memory until they are either removed or
replaced, and therefore can degrade server performance. *ession-state variables that contain blocks of
information, such as large datasets, can adversely affect :eb-server performance as server load increases.
A*5.67T session state supports several different storage options for session data. 7ach option is identified by a
value in the *ession*tate!ode enumeration. The following list describes the available session state modes
8n5roc mode, which stores session state in memory on the :eb server >A*5.67T worker 5rocess?. This is
the default. This mode offers the fastest access to these values. 4owever, when the A*5.67T worker
process recycles >if web application restarts?, the state data is lost. *o we go for 9ut-5roc modes as
described below.
*tate*erver mode, which stores session state in a separate process called the A*5.67T state service. This
mode uses a stand-alone !icrosoft :indows service to store session variables. ;ecause this service is
independent of 88*, it can run on a separate server. This ensures that session state is preserved if the :eb
application is restarted and also makes session state available to multiple :eb servers in a :eb form.
Although session variables are not lost if you restart 88*, performance is impacted when you cross process
boundaries. 8n this mode the worker process talks directly to the *tate *erver.
*13*erver mode stores session state in a *13 *erver database. This ensures that session state is preserved
if the :eb application is restarted and also makes session state available to multiple :eb servers in a :eb
farm. 4ere the worker process talks directly to *13.
,ustom mode, which enables you to specify a custom storage provider.
9ff mode, which disables session state.
5rofile 5roperties-A*5.67T provides a feature called profile properties, which allows you to store user-specific data.
This feature is similar to session state, except that the profile data is not lost when a user+s session expires.
The profile-properties feature uses an A*5.67T profile, which is stored in a persistent format and
associated with an individual user. The A*5.67T profile allows you to easily manage user information
without re/uiring you to create and maintain your own database. 8n addition, the profile makes the user
information available using a strongly typed A58 that you can access from anywhere in your application.
.ou can store objects of any type in the profile. The A*5.67T profile feature provides a generic storage
system that allows you to define and maintain almost any kind of data while still making the data available
in a type-safe manner.
To use profile properties, you must configure a profile provider. A*5.67T includes a */l5rofile5rovider class that
allows you to store profile data in a *13 database, but you can also create your own profile provider class that stores
profile data in a custom format and to a custom storage mechanism such as an B!3 file, or even to a web service.
;ecause data that is placed in profile properties is not stored in application memory, it is preserved through 8nternet
8nformation *ervices >88*? restarts and worker-process restarts without losing data. Additionally, profile properties
can be persisted across multiple processes such as in a :eb farm or a :eb garden.
;oth application state and session state information is lost when the application restarts. To persist user data between
application restarts, you can store it using profile properties.
:hat is @iew*tateC
(ie!State allo!s t"e state of ob)ects *serializable+ to be stored in a "idden field on t"e page, (ie!State is
transported to t"e client and back to t"e server and is not stored on t"e server or any ot"er e'ternal source,
(ie!State is used t"e retain t"e state of server-side ob)ects bet!een postabacks,
W"at is t"e lifespan for items stored in (ie!State-
.tem stored in (ie!State e'ist for t"e life of t"e current page, /"is includes postbacks *to t"e same page+,
W"at does t"e D7nable@iew*tateD property doC :hy would 8 want it on or offC
8t allows the page to save the users input on a form across postbacks. 8t saves the server-side values for a given
control into @iew*tate, which is stored as a hidden value on the page before sending the page to the clients
browser. :hen the page is posted back to the server the server control is recreated with the state stored in
viewstate.
:hat are the different types of *ession state management options available with A*5.67TC
A*5.67T provides 8n-5rocess and 9ut-of-5rocess state management. 8n-5rocess stores the session in memory on
the web server. This re/uires a Dsticky-serverD >or no load-balancing? so that the user is always reconnected to the
same web server. 9ut-of-5rocess *ession state management stores data in an external data source. The external
data source may be either a *13 *erver or a *tate *erver service. 9ut-of-5rocess state management re/uires that all
objects stored in session are seriali&able.
A*5.67T 5age 3ife ,ycle 9verview
:hen an A*5.67T page runs, the page goes through a life cycle in which it performs a series of processing steps.
These include initiali&ation, instantiating controls, restoring and maintaining state, running event handler code, and
rendering.
8n general terms, the page goes through the stages outlined in the following table. 8n addition to the page life-cycle
stages, there are application stages that occur before and after a re/uest but are not specific to a page.
0eneral Page Life-cycle Stages
Stage Description
5age re/uest The page re/uest occurs before the page life cycle begins. :hen the page is re/uested by a user,
A*5.67T determines whether the page needs to be parsed and compiled >therefore beginning
the life of a page?, or whether a cached version of the page can be sent in response without
running the page.
*tart 8n the start step, page properties such as 2e/uest and 2esponse are set. At this stage, the page
also determines whether the re/uest is a postback or a new re/uest and sets the 8s5ost;ack
property. Additionally, during the start step, the page+s -8,ulture property is set.
5age
initiali&ation
During page initiali&ation, controls on the page are available and each control+s -ni/ue8D
property is set. Any themes are also applied to the page. 8f the current re/uest is a postback, the
postback data has not yet been loaded and control property values have not been restored to the
values from view state.
3oad During load, if the current re/uest is a postback, control properties are loaded with information
recovered from view state and control state.
@alidation During validation, the @alidate method of all validator controls is called, which sets the 8s@alid
property of individual validator controls and of the page.
5ostback event
handling
8f the re/uest is a postback, any event handlers are called.
2endering ;efore rendering, view state is saved for the page and all controls. During the rendering phase,
the page calls the 2ender method for each control, providing a text writer that writes its output
to the 9utput*tream of the page+s 2esponse property.
-nload -nload is called after the page has been fully rendered, sent to the client, and is ready to be
discarded. At this point, page properties such as 2esponse and 2e/uest are unloaded and any
cleanup is performed.
Life-cycle &vents
:ithin each stage of the life cycle of a page, the page raises events that you can handle to run your own code. 0or
control events, you bind the event handler to the event, either declaratively using attributes such as onclick, or in
code.
5ages also support automatic event wire-up, meaning that A*5.67T looks for methods with particular names and
automatically runs those methods when certain events are raised. 8f the #uto&ventWireup attribute of the E 5age
directive is set to true >or if it is not defined, since by default it is true?, page events are automatically bound to
methods that use the naming convention of Page1event, such as Page1Load and Page1.nit. 0or more information
on automatic event wire-up, see A*5.67T :eb *erver ,ontrol 7vent !odel.
The following table lists the page life-cycle events that you will use most fre/uently. There are more events than
those listedF however, they are not used for most page processing scenarios. 8nstead, they are primarily used by
server controls on the A*5.67T :eb page to initiali&e and render themselves. 8f you want to write your own
A*5.67T server controls, you need to understand more about these stages. 0or information about creating custom
controls, see Developing ,ustom A*5.67T *erver ,ontrols.
Page &vent /ypical Use
5re8nit -se this event for the following
,heck the 8s5ost;ack property to determine whether this is the first time the page is
being processed.
,reate or re-create dynamic controls.
*et a master page dynamically.
*et the Theme property dynamically.
2ead or set profile property values.
.nit $aised after all controls have been initiali&ed and any skin settings >themes, 8ds? have been
applied. -se this event to read or initialize control properties.
8nit,omplete 2aised by the 5age object. -se this event for processing tasks that re/uire all initiali&ation be
complete.
5re3oad -se this event if you need to perform processing on your page or control before the 3oad
event.
;efore the 5age instance raises this event, it loads view state for itself and all controls, and
then processes any postback data included with the 2e/uest instance.
Load The 5age calls the 9n3oad event method on the 5age, then recursively does the same for each
child control, which does the same for each of its child controls until the page and all controls
are loaded.
-se the 9n3oad event method to set properties in controls and establish database connections.
%ontrol events -se these events to handle specific control events, such as a ;utton control+s ,lick event or a
Text;ox control+s Text,hanged event.
Note2
8n a postback re/uest, if the page contains validator controls, check the 8s@alid property of the
5age and of individual validation controls before performing any processing.
3oad,omplete -se this event for tasks that re/uire that all other controls on the page be loaded.