IIS finds the ASP file and submits it to the ASP engine (usually ASP.DLL) for processing, etc. Friends who need it can refer to it. First, let's understand the process of ASP page execution.
1. IIS finds the ASP file and submits it to the ASP engine (usually ASP.DLL) for processing.
2. The engine opens the ASP file and finds the content between <% and %>, and of course the content between <script runAt=server> and the corresponding </script>. These contents are called script blocks. Only the content in the script block is parsed by the engine, and other content is ignored and inserted between the script blocks as meaningless characters. It is necessary to explain that in fact, the content being parsed is more than this. The server-side include files of the <!--#include ***--> class are also included and processed by the engine. If you read a lot of programs, you will also know that some <object> objects whose runAt attributes are marked as Server will also be processed. We will not discuss them in depth here.
3. The engine executes the scripts in the script block. These server-side scripts are executed as a whole. That is to say, the following code can be written:
Copy the code code as follows:
<%
Dim i
For i=1 to 5
%> Hello World!
<% Next %>
The engine does not parse these script blocks separately, causing syntax errors in both script blocks. So we come to the following conclusion: not all non-server script code will be sent to the client. It is possible that this non-server script code is restricted by the script block. The server will definitely not worry about the execution of client scripts, but it can output different client scripts through server-side scripts.
4. Finally, the engine generates a text stream, or the execution result of the script, which can be considered as a string, which is the code of the web page sent to the client browser. The client browser displays the page. At this time, the source code (source file) of the page does not contain the server-side script, but contains the execution result of the server-side script (this is obvious).
<% … %> and <script runat=server>…</script>
They are all server-side scripts that are processed and executed at the same time. They perform as a unit.
<% … %> and <script language=…>…</script>
The former is a server-side script and the latter is a client-side script. The former is executed first and the latter is executed later.
In fact, this is not necessarily the case. It is possible for the two scripts to be executed at the same time, but the spaces are different. They are still: the former is executed on the server, and the latter is executed in the client browser. The former must logically be executed earlier than the latter. At the same time, we also came to the conclusion: During the execution of the same page, the client-side script cannot feed back to the server-side script in any case. That is to say, the client browses your guestbook and submits new messages or any value obtained by the client-side script. Neither can be processed in the same server response.
About component calls
Note that server-side scripts and client-side scripts are both scripts. Naturally, you can create xmlhttp components, ADODB.Connection components, etc., but they cannot be placed anywhere.
If xmlhttp is used to crawl web pages (such as collection) from the server, it must be created in the server script. If it is used for the client's ajax to access the server-side page in the background without refreshing, then it runs on the client, and naturally on the client Created on the end.
The ADODB.Connection component is used to access the database. Generally speaking, it is created on the server side. After all, it is the server-side asp program that runs the database data. But if your database is really connected on the client side, then there is no doubt that it will be created on the client side. Created in the client script.
In short, contradictory things and each side have their own characteristics. Different things have different contradictions; the same thing has different contradictions in different processes and stages of development; different contradictions in the same thing and two different aspects of the same contradiction each have their own particularities (you can omit those who do not understand) Don’t look…). This principle requires us to adhere to the principle of concrete analysis of specific problems, and under the guidance of the principle of universality of contradictions, concretely analyze the particularity of contradictions and find the correct method to resolve them. We are opposed to using one method to solve the contradictions of different things. This is what it means to open a lock with a key and sing whatever song you go to in any mountain.
Server-side VBScript scripts use the Server.CreateObject(className) method to create objects, and client-side VBScript scripts use the CreateObject(className) method to create objects.
Typical errors
Copy the code code as follows:
<%
FunctionTSize(b)
'This is my custom function
TSize=China
end function
%>
<a href=javascript:<%TSize('Variable')%> >Click here to use the function I defined</a>
Error analysis:
Confusing the difference between server-side scripts and client-side scripts. During actual execution, we will find that the client does not receive any code such as TSize at all, because TSize is a server-side program that is processed by the engine (note that the engine's processing of functions is purely for server-side script calls and will not sent back to the client) disappears and cannot possibly work on the client. This means that client-side scripts cannot directly call functions of server-side scripts.
In fact, this program has a syntax error. When the engine processes this content, it first finds the content between <% and %>, that is, <%TSize('variable')%>. Obviously, this content does not comply with VBScript syntax rules. Well, if you change it to <%=TSize(variable)%>, there will be no syntax errors in the server-side script. At this time, the TSize function can return the value China normally, so the href attribute received by the client is written like this: javascript: China, is unenforceable.
Impact of server-side scripts on client-side scripts
As mentioned before, server-side scripts are logically executed ahead of client-side scripts, so code like this is feasible:
Copy the code code as follows:
<%
Dim i
For i=1 to 5
Response.Write <script type=text/javascript> _
& alert('Hello World! & i & ')</script>
Next
%>
Regarding the execution of Response.Redirect and javascript
Note that the following code is written incorrectly:
Copy the code code as follows:
<%
Response.Redirect index.asp
Response.Write <script type=text/javascript> _
& alert('Wrong password!')</script>
%>
This is a common mistake. Writers often think that writing code in this way will cause the client to pop up a password error prompt and then redirect to index.asp. In fact, this cannot happen. Even if the order of the two lines of code is exchanged, it will not happen. It is possible to achieve this effect.
The reason is related to the way the server handles the two lines of code. It is impossible for these two lines of code to 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 it. Note that it can only be executed after receiving it.
Response.Redirect sends an HTTP header to the client (what is HTTP header? Let’s put it this way, for example, writing to client cookies is HTTP header information, and the HTTP header information is sent back to the client before the HTTP body Browser, this is why sometimes we get an error when modifying Cookies after turning off the server's buffering, because the body has already started transmitting and HTTP headers are not allowed to be sent. information.), the content of the information tells the client browser that it should jump to the page to browse. Note that this Redirect information is effective immediately, which means that this Redirect information is exclusive. When the buffer is turned on, regardless of whether Response has been used. .Write writes how much content is written into the buffer. Once Response.Redirect is called, the buffer will be cleared and this header instruction will be sent to the client browser. If we dynamically track the execution of the program, we will also find that after calling Response.Redirect, the program stops executing, so please note that the server-side program must close the data connection and other operations before calling Response.Redirect.
So how should the above example be modified? If you are unwilling to modify the index.asp to add a script prompt, you can only execute the redirection instruction in the client script, like this:
Copy the code code as follows:
<%
Response.Write <script type=text/javascript> _
& alert('!');location.href='index.asp'</script>
%>