The difference between Server.Execute and Execute in ASP to implement dynamic include scripts, friends in need can refer to it. I recently planned to try to implement the MVC architecture in ASP. Someone must have asked me: ASP has been eliminated, why are I still studying it? I also know this. Since Microsoft gave up ASP 3.0 and switched to ASP.NET, ASP has lagged far behind PHP and JSP, which started almost at the same time. The benefits of open source over closed source are the same as PHP and ASP. ASP is said to be eliminated. No one can save it from being eliminated, but it is worth noting that ASP is still quite widespread in the Chinese market, especially for some applications of some small and medium-sized enterprises. Simple CMS is not a problem, and it is easy to deploy. On some old Windows systems, No need to install .NET Framework can basically be run directly, so it is still necessary to prepare a framework. However, my framework is an experimental framework, just to verify whether ASP can implement an MVC architecture similar to PHP.
Okay, having said so much, let’s get straight to the point. The reason for this problem is that I need to dynamically include ASP files. As we all know, there is only one include method in ASP, which is SSI (Server Side Include), which is basically divided into the following two types:
Copy the code code as follows:
<!-- #include file=sample.asp -->
<!-- #include virtual=sample.asp -->
Basically, the first one is more commonly used of these two. #include virtual contains the virtual path, which is generally used in virtual directories. But both of these are static. If we want to include it dynamically, it cannot be written as:
Copy the code code as follows:
<!-- #include file=<%=MyVar%> -->
<!-- #include virtual=<%=MyVar%> -->
The above writing is wrong. It can be understood that the #include directive is executed before ASP starts the script engine and executes the script between the ASP<% %> tags. In other words, #include is not the work of ASP, but the server program. Such as IIS translation work, so it will not pay attention to your ASP code.
How to implement dynamic inclusion script methods similar to PHP's include, include_once, require, and require_once? Let's look at a method of the ASP Server object: Server.Execute. Searching all ASP features, we can find that this function is most similar to dynamic include. We can do an experiment:
Sample.inc.asp
Copy the code code as follows:
<%
Response.Write Hello World!
%>
test.asp
Copy the code code as follows:
<%
Server.Execute Sample.inc.asp
Response.Write I am test.asp!
%>
The actual output should be Hello World!I am test.asp!, indicating that Server.Execute can work well with dynamic inclusion, but what if I want to include a class or function? Next do the following experiment:
Sample.class.asp
Copy the code code as follows:
<%
Class Sample
End Class
%>
test.asp
Copy the code code as follows:
<%
Server.Execute Sample.class.asp
Response.Write TypeName(Eval(New Sample))
%>
Run it directly, and the error Microsoft VBScript runtime error '800a01fa' class is not defined: 'Sample', the result is very disappointing, why does this happen? I checked MSDN and found this description: If a file is included in the calling page by using #include, the executed .asp will not use it. For example, you may have a subroutine in a file that is included in your calling page , but the executed .asp will not recognize the subroutine name. It seems to be somewhat different from the problem I encountered. Is Server.Execute code isolated? Then conduct the following experiment:
Sample.inc.asp
Copy the code code as follows:
<%
Dim MyVar
MyVar = I am Sample!
%>
test.asp
Copy the code code as follows:
<%
Dim MyVar
MyVar = I am test!
Server.Execute Sample.inc.asp
Response.Write MyVar
%>
The output is I am test!, which is very disappointing! It seems that Server.Execute isolates variables, functions, classes and other codes, which means that the calling end and the called end do not interfere with each other at the code level. It seems that Server.Execute can only be used to include .asp templates.
The following is the VBScript script feature Execute. What is passed to Execute must be a valid VBScript script code, and Execute is context-sensitive. This seems to be very close to the dynamic include we need.
test.asp
Copy the code code as follows:
<%
Execute Class Sample : End Class
Response.Write TypeName(Eval(New Sample))
%>
The above code successfully outputs the type name Sample we need. It proves that Execute can indeed be context-sensitive, but the problem is that using Execute to include asp files is not as convenient as Server.Execute. Execute comes with VBScript scripts. First of all, it can only be used to execute code text, so the file content needs to be read once. Secondly, it cannot Some tags used to identify ASP, such as <% %>, there is a calling method similar to <%=MyVar %>, so you need to filter out <% %>, and then convert <%=MyVar %> to Response.Write MyVar. Since what I need is to include class files, <%=MyVar %> will not appear. I just need to simply replace <% %>. For reading file contents and simply excluding <% %>, you can refer to the following function:
Copy the code code as follows:
Function file_get_contents(filename)
Dim fso, f
Set fso = Server.CreateObject(Scripting.FilesystemObject)
Set f = fso.OpenTextFile(Server.MapPath(filename), 1)
file_get_contents = f.ReadAll
f.Close
Set f = Nothing
Set fso = Nothing
End Function
Function class_get_contents(filename)
Dim contents
contents = file_get_contents(filename)
contents = Replace(contents, < & %, )
contents = Replace(contents, % & >, )
class_get_contents = contents
End Function
With the above function we can directly test the following code:
Sample.class.asp
Copy the code code as follows:
<%
Class Sample
End Class
%>
test.asp
Copy the code code as follows:
<%
Execute class_get_contents(Sample.class.asp)
Response.Write TypeName(Eval(New Sample))
%>
The result output is the Sample type name we expected. It seems that Execute is still very powerful. It is indeed very powerful, because people with bad intentions often use it to make ponies. The simplest ASP one-sentence Trojan is probably written as the following sentence. :
Copy the code as follows: <%Execute Request(c)%>
For example, this script is located in file.asp, and then pass in file.asp?c=Trojan text, haha, you already know the following thing. Okay, this is a digression. Another thing to note about Execute is that it is context-related, so pay attention to the scope issue. If Execute is located inside a Sub process or Function function, it is inaccessible from outside.