Uncovering the sequence of execution of ASP scripts

First of all, we first look at the implementation of ASP page process: 1.IIS to find ASP files, submitted to the ASP engine (generally ASP.DLL) processing.

I believe that many web site producers like me, only focus on the development of technology, skills. But ignores its principle, this article will carry on the introduction to the ASP execution procedure.

First let's take a look at the process of ASP page execution
1.IIS to find the ASP file, submitted to the ASP engine (generally ASP.DLL) processing.
2. The engine opens the ASP file to find the content between <% and%>, and of course <script runat= "Server" > and the corresponding </script> content, which is called the script block. Only the contents of the script block are parsed by the engine, and other content is inserted between the script blocks as meaningless characters. It is necessary to explain that there are more than these,<!--#include the server-side containing files of ***--> classes are also included and processed by the engine. If you read more programs, you will also know that some of the runat attributes labeled "Server" <object> objects will also be processed, without further discussion.
3. The engine executes the script in the script block, and the server-side scripts are executed as a whole, that is, you can write the following code:
<%
Dim I
For I=1 to 5
%> Hello world!
<% Next%>
The engine does not parse the script blocks separately, making the two script blocks syntactically incorrect. So we've come to the conclusion that not all non-server script code is sent to the client, and it is possible that the non-server script code is limited by the script block. The server is sure not to worry about the execution of the client script, but it can output different client script from the server-side script.
4. The final engine produces a text stream, or the execution result of the script, which can be considered a string, or code that is sent to the client browser's Web page. The client browser displays the page, at which point the source file contains no server-side script, but includes the results of the server-side script execution (which is obvious).

<% ...%> and <script runat= "Server" >...</script>
They are both server-side scripts that are processed and executed. They are executed as a whole.

<% ...%> and <script language= "..." >...</script>
The former is the server-side script, and the latter is the client script. The former executes first, the latter later.
In fact, the two scripts are likely to be executed at the same time, but the space is different, the former is performed on the server, the latter in the client browser. The former is logically bound to advance in the latter's execution. At the same time we concluded that client script could not be fed back to server-side scripts in the same page, that is, clients browsing your message book and submitting a new message or any of the values obtained by any client script could not be processed in the same server response.

Calls on components
Note that both server-side and client script are scripts, and you can naturally create XMLHTTP components, ADODB. Connection components, but not anywhere.
XMLHTTP If a crawl page for a server (such as a collection) is created in a server script, and if the Ajax for the client is not refreshed and the backend accesses the server-side page, then it is run on the client, which is naturally created on the client.
ADODB. The connection component is used to access the database, generally on the server side, after all, is the server-side ASP program running database data, but if your database is really connected at the client, then there is no doubt in the client script created.
in short, contradictory things and each side of each has its own characteristics. Different things have different contradictions, the same thing in the development of different processes and different stages have different contradictions, the same thing in different contradictions, the same contradictions in the two different aspects of each has its own particularity (can not understand the omission to see ...). ）。 This principle requires us to adhere to the specific principles of concrete analysis, under the guidance of the principle of universality of contradictions, concretely analyze the particularity of contradictions, and find the correct way to solve the contradictions. Opposition to the use of a method to solve the contradictions of different things. "Key starts locks, to what mountain to sing what song" Is this truth. The
server-side VBScript script Creation object uses the Server.CreateObject (ClassName) method, and the client VBScript script creates the object using the CreateObject (ClassName) method.

Typical error
<%
Function Tsize (b)
' This is my custom function.
Tsize= "China"
End Function
%>
<a href= "javascript:<%tsize (' variable ')%>" > dot here to use the function I defined </a>
Error Analysis:
Confusing server-side script with client script. In practice, we will find that the client does not receive anything like Tsize code, because the tsize is the server-side program, after the engine processing (note that the engine for the function of the processing, purely to server-side script calls, not sent back to the client) disappeared, it is not possible to function on the client This means that client script cannot directly invoke a function of a server-side script.
In fact, the program is grammatically incorrect, and the engine processes this content by first finding the content between <% and%>, the <%tsize (' variable ')%>, which obviously does not conform to VBScript's grammatical rules. Well, change to <%=tsize ("variable")%> the server-side script there is no syntax error, then the Tsize function can return the value of the normal "China", so the client received the HREF attribute is this: "JavaScript: China", is not executable.

The impact of server-side scripting on client script
As already mentioned, the server-side script is logically ahead of client script execution, so this code is possible:
<%
Dim I
For I=1 to 5
Response.Write "<script type=" "Text/javascript" ">" _
& "alert (' Hello world! ' & I &" ') </script> "
Next
%>

About the implementation of Response.Redirect and JavaScript
Note that the following code is incorrectly worded:
<%
Response.Redirect "Index.asp"
Response.Write "<script type=" "Text/javascript" ">" _
& Alert (' Password wrong! ') </script> "
%>
This is a common mistake, the writer often thought, this writing code can let the client first pop-up "password error" prompt then turn to index.asp, in fact this is not possible, even if the two lines of code exchange, it is impossible to achieve this effect.
The reason for this is related to how the server handles the two lines of code. These two lines of code cannot work at the same time.
Response.Write is to send a piece of text to the client, the content of this text can be a script, then the client browser can execute the script after receiving, note that to receive before execution.
Instead, Response.Redirect sends an HTTP header message to the client (what is HTTP header information?). To put it this way, for example, the write to client cookies is HTTP header information, HTTP headers are sent back to the client browser before the main body of HTTP, which is why sometimes we can make changes to the cookies after the server's buffering is closed, because the main body has already started to transmit, HTTP header information is not allowed to be sent. , the content of the information tells the client browser should jump page browsing, note that this redirect information is immediately functional, that is, this redirect information is exclusive, in the case of buffer open, Regardless of how much content has been written to the buffer using Response.Write, once the Response.Redirect is invoked, the buffer is emptied and the header is sent to the client browser. If we follow the execution of the program dynamically, we will also find that the program stops executing after the call to Response.Redirect, so note that the server-side program should do the data connection shutdown before calling Response.Redirect.
So how should the example above be modified? If you don't want to modify that index.asp to add a script hint, you can just put the steering instructions in the client script, like this:
<%
Response.Write "<script type=" "Text/javascript" ">" _
& "Alert" ('! '); location.href= ' index.asp ' </script> '
%>