After two days of hard work, I finally migrated the PHP website from Apache to IIS7. I encountered some problems during the migration process. I will share them with you here. I still have a problem, I hope you can help me.
This article will not cover the following content:
If you want to know the above content, you can go to the http://www.iis.net and http://www.php.net websites to view the relevant content. Many references can also be found in search engines.
Configure the PHP running environment using FastCGI on IIS7.0. After testing that the PHP program can run normally, deploy the PHP program and import the original data and configuration information of the program. Since the Apache server is occupying port 80, stop Apache first and set IIS7.0 to use port 80 to run the website. The PHP program finally started running on IIS7.0, and it looks pretty good, haha...
But it seems that I was happy too early, and problems will arise soon L
My colleague found that many pictures could not be displayed. I feel very strange. Since there is no problem on Apache, after migrating to IIS7.0, the domain name and file path have not changed, so there should not be a problem. I immediately started to confirm and troubleshoot the problem. First, I checked the page based on the information provided by my colleagues. Sure enough, many pictures could not be displayed. Then, I randomly looked at the pictures on the website and found that some pictures could be displayed normally, and some pictures could not be displayed normally. All paths contain Japanese or Chinese characters. Why is this? ? ?
After a lot of crazy tossing, I still have no clue. I have no choice but to reopen a picture in the browser. I hope I can find something useful from the error message. There is only a 404 File Not Found error and nothing else. Value reference information. At this time, I connected to the server remotely and accessed it on the server, haha... The error message was more detailed, as shown below:
OMG, UrlScan rejected the request. Open a log file in UrlScan's log directory C:WindowsSystem32inetsrvurlscanlogs and find many records similar to "Rejected URL contains high bit character URL". Why is this? ? ? It turns out that after UrlScan is installed on IIS7.0, all requests will be filtered by aspnet_filter and Request Filtering. The filtering rules of Request Filtering are in the UrlScan installation directory C:WindowsSystem32inetsrvurlscanUrlScan.ini file. There is such a rule AllowHighBitCharacters=0, IIS The explanation from the official website is: This feature either allows or rejects all requests to IIS 7 that contain non-ASCII characters and logs the error code 404.12, allows or rejects all requests that contain non-ASCII characters and logs the error code 404.12 ASCII character request and record 404.12 error in the log. The rule defaults to 0 , that is, requests containing high-bit characters URL are rejected. We changed the value of AllowHighBitCharacters to 1, and the image can finally be displayed normally.
Regarding the configuration of AllowHighBitCharacters, the rules configured in UrlScan.ini are at the entire machine level and are applicable to all websites on IIS7.0. According to the instructions on the IIS official website, it can also be configured at the website level. In IIS Manager, you can select the specified website on the left, select "Request Filtering" in the middle functional area, double-click the feature, click "Edit Feature Settings" in the right operation area, and select or cancel The "allow high-bit characters" item is enough; you can also add the following content directly to the website's web.config:
However, according to my test, if AllowHighBitCharacters=0 is configured in UrlScan.ini, then configuring AllowHighBitCharacters="true" in web.config at the website level as above will not work at all, and IIS7.0 still refuses Handle requests that contain non-ASCII characters in the path; if AllowHighBitCharacters=1 is configured in UrlScan.ini, then configuring AllowHighBitCharacters="true|false" in web.config as above at the website level will take effect.
Why is this? I hope someone can give me some guidance.
2.
Fortunately, every step of the way leads to wisdom. This time I went to look at UrlScan's logs and found that many of the records of loading JS were "Rejected URL contains dot in path URL". Then I looked at the configuration in UrlScan.ini. There is an AllowDotInPath configuration under AllowHighBitCharacters. The default value is also 0, which means that dot characters [.] other than the extension are not allowed to appear in the Url. As we all know, the JQuery library and many extension plug-in files have dot characters [.] .], change the value of AllowDotInPath to 1, and there will be no problem opening the website, haha:)
Note: Regarding AllowDotInPath in UrlScan.ini, it is not recommended to set it to 1 except for testing, because if set to 1, extension-based checks will no longer be trusted.
After these two problems are solved, the migration of the PHP program from Apache to IIS7.0 is completed.
Finally, there is another problem. Our PHP website is running on IIS7.0. When accessing, the page will occasionally be blank. Just wait for a while and then directly recycle or restart the process. It will be fine after the pool, but I don’t know what the problem is? I hope that there are garden friends who understand this problem and will not hesitate to enlighten me and give some pointers. Thank you in advance!
Note: This problem has been solved. The specific operation is to reduce the http connection time and increase the maximum number of connections and the number of concurrent connections in the application pool.
Reference: