Catching 404s

Topics: User Forum
Nov 20, 2009 at 10:41 AM


I like to think I'm ok with how RegExp works and how the filter applies, but I seem to be breaking one of our sites at the moment and was wondering if you could help.

Using version 2 now, the .ini file bits that are relevant (happy to post the whole thing) are:

RedirectRule  ^/index\.(asp|php)$		/ [I,R=302]

# If we get here, then it's not a valid page RewriteCond %{HTTP_URL} (\.html|\.php|\.asp|\.htm) [I] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^.*$ /pages/404.asp [U,I,L]

Essentially, I'm redirecting /index.asp to just / to keep the address bar clean. Putting in a spoof address, eg. /foo.asp causes the custom 404.asp page to show, but currently putting in /foo doesn't.

I've tried amending the first RewriteCond line to check against


instead, but this causes a script to error. The script is finding out dimensions on a given image to know how to display it. The error it's throwing up seems to be a permissions error, even though the permissions on the server are right, as proven by the fact that it works fine without amending that line.

I've then tried to combat this by adding in

RewriteRule ^/$  - [U,I,L]

but this doesn't seem to work either, it still causes this script to fail. Unfortunately it seems the only way to bring this back round is to restart IIS, which is less than desirable as it's a production box with a few sites on it.

Any clues? I'm hoping it's something obvious that I'm missing.



Nov 20, 2009 at 2:15 PM
Edited Nov 20, 2009 at 2:19 PM

Hey shonk, let me understand what the basic problem is.  What you are currently seeing is this: when a URL request with an extension is sent in, like http://server/foo.asp ,  and that page does not exist, then you get the 404 page ( /pages/404.asp ) as expected.    Is that right?   And When you send in a request without an extension, like http://server/foo , and that page does not exist, then... you get... what??

What you want to see is, the 404 page to be displayed when a URL request without an extension is sent in, and that page does not exist.

What would be helpful is if I could see the IIRF log file for a request like http://server/foo .

Nov 23, 2009 at 10:12 AM

Hey Cheeso,

Thanks for the response.

I'm a little loathe to set the live site to break again, so I'll see if I can get it to fail the same way on a test server today. I'll get back to you with log files and a more in-depth description of the errors.

Thanks again, will be in touch.


Nov 23, 2009 at 5:37 PM

Ok, trying to set this up on a local server...

Can I please just check something as I can't get this working at all... =)

If I see the line

Mon Nov 23 17:32:57 -  3644 - DoRewrites: Redirect (code=302) Url to: '/news/page/1'
then it should be redirecting my browser right? Because it isn't, it's just sitting there giving me a blank page - yep, nothing on it at all... Strange?

Nov 23, 2009 at 5:42 PM

Ok, rewrites seems to be working ok, but redirects not. Server setting? Also, when I enter the URL /index.asp it's not loading that page... I will look in to this further and report back any findings, but it may be tomorrow at this rate...

Nov 24, 2009 at 12:37 PM
Edited Nov 24, 2009 at 12:39 PM

yes - a line in the log file like

DoRewrites: Redirect (code=302) Url to: '/news/page/1'

indicates that the filter thinks it is replying with an HTTP 302 response, and the given target site.  You can verify that this response is actually happening via something like Fiddler, which will trace the HTTP communications back-and-forth.

There can be other intermediaries in the chain that could prevent that URL request from arriving at the client, or being sent successfully back to the server.  Like UrlScan or something - that could prevent any arbitrary URL from reaching the server. The fidder trace should show you what is happening.


Nov 24, 2009 at 4:24 PM

Ok, just to let you know, and in case it helps anyone else along the way, it was my server misbehaving.

I was using port numbers due to the number of test sites running and this was causing the Redirect to fail for whatever reason - still don't know.

What I've done, is add a new DNS zone, picking up on a new extension (.dev) and now that the site is running using, rather than domain:port the redirects are working fine.

Now, back to testing the ini file so I can get back on topic.