0

I've inherited an old system after starting a new job, none of the previous developers work here any more and none of them documented all that much. Fun times.

The system uses an old, defunct CMS and I've just finished a large ordeal whereby I could not for the life of me figure out how routing worked (the client wanted a URL changing). It later turned out that the previous developers had been using a completely separate program called "Helicon ISAPI rewrite" and had been doing all of the site's URL management from there.

My question is: How could I have figured this out more quickly (e.g. are there external tools I could have used or logs I don't know about that would have revealed how this routing was working)?

I spent a whole afternoon picking through 10 years worth of code when the answer wasn't even in there! Right now I'm feeling that I had no chance of figuring that out quickly but I'm wondering if I'm missing something.

Mikey Hogarth
  • 4,672
  • 7
  • 28
  • 44

2 Answers2

1

I think I understand what you're asking, to discover the rewriting in the first place. Tony's answer is right if you knew about ISAPI_Rewrite up front, but hindsight is 20-20. I'm a big fan of ISAPI_Rewrite and Helicon Ape, so I might have suspected it. However, if the rewriting was being done by IIS7's .NET web.config, I wouldn't have looked there (although I guess web.config should be a place to start for anything IIS-screwy). With a legacy CMS or something like WordPress, I wouldn't know where to start, so I would probably start with the code like you did.

I suppose the real starting point is the top of IIS, before the request even gets to the web code.

Looking around in IIS7, I see Handler Mappings, with a whole bunch of stuff in there, intercepting various requests. These could all "do things" to the request before it hits the website. e.g., I see Microsoft's ExtensionlessUrlHandler... which gave us troubles as a breaking changing when upgrading to .NET 4.0. We had to dig around for this, wondering what was putting eurl.axd into our urls.

IIS6 has an ISAPI Filters tab on the website properties. Mine has ISAPI_Rewrite and ASP.NET_2.0.... in it. There's also an HTTP Headers tabl with MIME types, that can be a culprit for diverting requests.

Knowing this now, perhaps a list of all rewriting software would be handy. Just search the system for any of them installed - might be the fastest way to a get the first clue.

And actually, if you spent an afternoon in 10 years of code, that's not too bad! So you may not have had a chance of figuring this out quickly - any legacy system is going to have buried secrets.

goodeye
  • 2,389
  • 6
  • 35
  • 68
0

If it's ISAPI_Rewrite v3, you can enable logging in httpd.conf in ISAPI_Rewrite installation folder by putting the following lines:

RewriteLogLevel 9
LogLevel debug

Then after you make some test request, the rewrite.log and error.log file will appear in ISAPI_Rewrite installation folder. error.log shows general issues, while rewrite.log shows how and if the rules are applied and what the resulting URL is.

TonyCool
  • 1,004
  • 1
  • 6
  • 5
  • Thanks for the reply - it's not so much logging it once it's there though, I want to know how I *could have known* that it was there (e.g. what traces etc. could I have used to identify that ISAPI rewrite was occurring). – Mikey Hogarth Sep 05 '12 at 11:04