Get and post in HTTP, ViewState principle

HTTP is the model of the request, the response, the server does not come to read the browser Web page, only can get the data submitted by the client.
When the user clicks Submit, the server knows "submit back" (PostBack)

Get vs. Post

Set the method property of the form to specify how the form is submitted, and get (the default value) is passed by URL value, the amount of data passed is limited
Post-pass form values are hidden in the HTTP message, the URL is not visible, there will be a browser prompt to resubmit the form of the problem, get no
Get mode URL data format, server file name followed by "? ", because the client may submit multiple key-value pairs to the server,
The key-value pair is split with "&", and if the URL has Chinese characters, special symbols, etc., the URL needs to be encoded
The form field will be submitted to the server only if name is set.

Web page only the Value property of the Input,textarea,select that has the name set will be submitted to the server
Non-form elements cannot pass values to the server's
such as: To set the value of the Div, directly is not possible, can be implemented by hiding the field, the value of the hidden field is set to the same as the Div content
Then when the user submits the information, the server obtains the value of the hidden field and replaces the value with all the values of the page

If the From form method property is specified as GET, then the action=1.ashx?a=123 parameter is deleted
If specified as post, the arguments in the action are submitted to the server to

ViewState principle (for solutions to the above problem)

The value of the label version is stored in the ViewState, and the textbox version does not exist, because the textbox is input and is submitted to the server, and no hidden fields are required.
Used for ASP. div Text self-increment (also increment label width, note the unit of width)
Label1.Text = (Convert.ToInt32 (label1.text) +1). ToString ();
Label1.width = new Unit (Label1.Width.Value + 10);
To view the generated source code, ASP. NET puts all the hidden content in a hidden field named __viewstate, using serialization
The algorithm puts all the hidden content into a string and clicks on the tool using Viewstatedecoder to view the ViewState
Content, and found that these changes were actually put in the ViewState

How to disable ViewState: Add Enableviewstate= "false" to the top page tab, disable ViewState after
The textbox version is not affected, and the Div version is affected because the value of input does not depend on ViewState (a single control can be disabled)
Disabling ViewState does not completely remove the viewstate, there will be a small piece of code, if you want to be in the page completely viewstate
Then there can be no runat=server form in the page, if the button and other service-side controls are not placed in the Runat=server form
, then it's not necessary.

When answering the ViewState principle, say: Input version (TEXTBOX) is different from increment and div version (Label)

---------ViewState Use:

     //Assigning a value to ViewState in the background           This. viewstate["Key"] ="004";  This. Viewstate.add ("Key2", the); //Call ViewStateLabel1.Text = This. viewstate["Key"]. ToString ();

As long as there is a runat=server form will produce _viewstate and so on, so remove the form runat=server, so that in addition to a few controls such as repeater, server control can not be used, only use HTML tags.
This is why it is said that "high-demand Internet projects do not have server-side controls"

Stateless HTTP

1.HTTP protocol is stateless, will not remember the last and the page "What happened", if you want to know the last state,
One way to do this is to save the state information to the page form before the browser response is finished, and the next page will send a request to the server
With these status messages so that the server can restore the last state based on these state information.
2. The disadvantage of saving state information in hidden fields: increase the traffic of the website, reduce the speed of access, and put the confidential data into the form there will be data spoofing and other security issues

Cause: HTTP is the TCP protocol used, in order to reduce the consumption of the server, when the server responds to the client, then immediately segment off, so no state

Asp. NET saves state in the following ways:

Application Current application (all users use one application)
Session Current Sessions (one session per user)
Cookies are stored on the client's
ViewState for the current page (one viewstate per page)

First, Application Object

Application is global, save and operate on the server side, anyone can access

Save with Object
This. application["T1"] = TextBox1.Text;
Application.Lock ();//Lock
Application.UnLock ();//unlock

Can be in the Global.asax of the page access, click to do some statistics

Second, the use of cookies

A cookie exists on the client
Cookies are site-related, and each time a request is made to the server, in addition to the form parameters are sent, all site-related
Cookies are submitted to the server, are mandatory, cookies are stored on the browser side, and the browser will be on every request
The cookie that is associated with this site is submitted to the server and the cookie returned by the service is updated back to the database so that the information can be
Save the cookie and then read and modify it on the server side.
The server returns data in addition to normal HTML data, the modified cookie is returned, and the browser updates the value of the cookie to the local
The browser's cookie can be

Set up:

Response.setcookie (new HttpCookie ("Color", TextBox1.Text));

Or

RESPONSE.COOKIES.ADD (new HttpCookie ("Size","$") );

Read:

Lable1.text = request.cookies["Color"]. Value;

Extended use:

New HttpCookie ("Color", TextBox1.Text);    //  H1. Expires = DateTime.Now.AddHours (1);    // set expiration time, only in datetime format true;    // set whether the client can access the script Response.setcookie (H1);    // Set Cookies Response.appendcookie ();    // Append Cookies

The disadvantage of cookies, like forms, cannot store too much information.

Website Optimization case:
Web site image server to be different from the main site domain name, reduce the transfer of cookie traffic
Note: Images, css,js and other static files are all separate requests.

If a website has more than one map, there is a local cookie on that website,
Then, when accessing, request HTML to pass a cookie once, request each picture to pass a cookie again, this is wasted.
If the domain name of the image server is not the same as the master station, the cookie will not be transmitted when the image is downloaded.
Because cookies are not cross-domain!!

Third, the session principle

Session is stored on the server side, the object type is stored
private int i = 0; Every time a request comes, a new instance of the class "variable" that implements the IHttpHandler interface
Processing, the GC is out of use, so the last value will not be maintained, so it will not be self-increasing
private static int j = 0; Static is not instantiated, and all visitors access the same instance of J.
The last value is still saved, so it will increment itself
Cookies cannot store too much information, and if you want to save a large amount of data, you can save a GUID to a cookie, and then create a GUID key in the server, and the complex data as the value Global dictionary,static field for different users only one copy,

Therefore, using static to implement multi-user shared data, the code is as follows:

 Public classSessionmgr//Session Management Page{    Private Staticidictionary<string,idictionary<string,Object>> data =Newdictionary<string,idictionary<string,Object>>();  Public Staticidictionary<string,Object> getsession (stringsessionId) {        if(data. ContainsKey (sessionId)) {returnData[sessionid]; }        Else{IDictionary<string,Object> session =Newdictionary<string,Object>(); Data[sessionid]= Session;//add value for data, SessionID to key,session as value            returnsession; }    }   }    protected voidPage_Load (Objectsender, EventArgs e)//Load Events    {        if(request.cookies["Mysessionid"] ==NULL)//judge whether there is mysessionid, not increase        {            stringSessionId =Guid.NewGuid ().            ToString (); Response.setcookie (NewHttpCookie ("Mysessionid", sessionId)); }    }    protected voidBtus_click (Objectsender, EventArgs e)//Set Session Click event    {        stringSessionId = request.cookies["Mysessionid"].        Value; IDictionary<string,Object> session =sessionmgr.getsession (sessionId); session["data on the service side"] = DateTime.Now;//Add a key value    }    protected voidButd_click (Objectsender, EventArgs e)//Read Session Click event    {        stringSessionId = request.cookies["Mysessionid"].        Value; IDictionary<string,Object> session =sessionmgr.getsession (sessionId); Butd. Text= Convert.ToString (session["data on the service side"]); }

ASP. NET has built-in session mechanism, the above example with Asp.netsession rewrite,
Note: Do not put too many objects into the session,session there will be a mechanism for timeout destruction
You can see that the session mechanism is not specified by the HTTP protocol, is the implementation of ASP, and now php,jsp and so on most of the service-side technology
I realized the session, the principle is similar
If the user disables the Session, you can add properties to the <system.web> inside the web.conf to save Seesionid to the URL, <sessionstate cookieless= "UseUri"/ >

Asp. NET built-in Session

session["one"] = DateTime.Now;            // Set Value Label1.Text =convert.tostring (session["one"]);    // Take value

Get and post in HTTP, ViewState principle