URLScan basically just scans the URL of all incoming requests, and parses the URL... looking for request elements that are NOT allowed (as defined in URLScan's initialization file). If URLScan sees an extension or a hack it doesn't like (like .exe or .. for a directory traversal hack) it stops the request cold. In other words, it does not allow the request to proceed through any remaining IIS filters (of which ServletExec is one). Therefore the request is never handed over to ServletExec.
So ServletExec never receives the request... URLScan has blocked it.
URLScan may also be configured to look for http verbs (GET, POST, HEAD, etc...) it doesn't like so you can stop things such as WebDAV (or whatever else you want URLScan to block). URLScan can also stop long requests to block buffer-overrun attacks.
If URLScan is configured properly, then ServletExec won't be effected at all, and will work just fine.
If you have URLScan hooked into your IIS, and you're having problems getting ServletExec to function properly behind IIS, then you may very well need to configure your URLScan differently.
URLScan would be configured by editing this file:
So maybe go look on your hard-drive for that file.
Some common configuration changes that must be made to URLScan after SE has been installed with IIS include:
URLScan *may* be included with certain Microsoft updates such as the IIS lockdown tool.
Please see FAQ #186 for more information.
- Telling URLScan to allow the .jsp extension
- Telling URLScan to allow the /Scripts Virtual Directory to be used (or setting up a different VD for SE to use)
NOTE: We've had customers tell us that after configuring their URLScan's configuration file properly, SE and URLScan both worked fine with the same IIS installation. So we know that this is possible to do.
Here are 3 other places to learn more about the URLScan tool from Microsoft: