I have run multiple PHP (Laravel) applications on my IIS 8 (Win 2012) Server. This is the web.config
file for all of my apps:
<configuration> <system.webServer> <rewrite> <rules> <rule name="Imported Rule 1" stopProcessing="true"> <match url="^(.*)/$" ignoreCase="false" /> <conditions> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" /> </conditions> <action type="Redirect" redirectType="Permanent" url="{R:1}" /> </rule> <rule name="Imported Rule 2" stopProcessing="true"> <match url="^" ignoreCase="false" /> <conditions> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" /> <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" /> </conditions> <action type="Rewrite" url="index.php" /> </rule> </rules> </rewrite> </system.webServer> </configuration>
But on one appliation, IIS make from time to time a problem: My app don't work, because the URLs are wrong. If i restart the Webserver OR change the web.config
file (add a empty space or something...), it works again.
I have no idea...my other apps works without problems, and it's the same web.config
code.
All Users (IIS_IUSR, Admins, etc) have full write and read access.
My apps are structured in folders, see here:
And i call it with 10.0.0.7/doku
or 10.0.0.7/lagerverwaltung
.
2 Answers
Answers 1
When using IIS I would consider converting each of the specific site folders (doku, lagerverwaltung, etc.) into their own application. That way there will be no confusion over which web.config file is being used when loading and further the apps could then run inside their own app pool and threads.
To do this, inside IIS right click on the specific folder you wish to convert and click on "Convert to Application" in the context menu which opens up. In the subsequent screen you can choose an existing or new Application Pool and also setup any required pass-through authentication you may need.
Forcing the sub-sites to run inside their own application pool and use their own web.config file specifically should eliminate your issue with potential fallback to a base web.config.
Answers 2
A systematic approach for finding the root of the issue could be enabling failed request tracing in IIS as explained here:
Once you enabled failed request tracing, take a look at the HTTP pipeline and inspect how your rewrite rules are being handled.
Also, you can use process monitor and see what exact files your app pool is accessing. I would filter it by (1) the folder you site reside, then (2) the application pool identity (3) the application pool process ID. Use this article to find the App Pool's PID: https://blogs.msdn.microsoft.com/ericparvin/2014/04/29/find-pid-for-iis-application-pools-worker-process/
You need to use process monitor when there is no load on your server, so you don't get a flood of process events.
With above techniques, you should be able to nail down what is going on on the mischievous application.
Good luck!
0 comments:
Post a Comment