Rewrite without having to modify web files.

Topics: User Forum
Sep 26, 2008 at 5:02 PM
I have installed URL rewrite on a number of IIS 6, 7 servers.

The problem I am having is that images and links do not work without a leading slash '/'
What must I do to resolve this issue, so that I do not have to go into each and every script or html file and and a slash in front of every relative URL?

Oct 1, 2008 at 10:28 PM
sorry, I totally don't get it!
I don't get the problem. 
you're gonna have to be more specific.

what does it mean "do not work"  ??
what results do you see?
what results do you expect to see?
Oct 2, 2008 at 2:48 PM
Edited Oct 2, 2008 at 2:50 PM
Before I installed IIRF on IIS (6 and 7) images and links worked fine in webpages.

After installing IIRF on IIS as a filter in the IIS Manager, I noticed images and external styles disappeared, so using firebug in Firefox 3 i notice the the link had extra information in them for example:

Where before IIRF installed all relative links looked something like this:
     <img src="images/button_1.jpg" /> and <form action="search.asp" method="post">
Changed to this:
    <img src="/search/Fry-Pans/images/button_1.jpg" /> and <form action="/search/Fry-Pans/search.asp" method="post">

So as a temorary fix to solve the issue, I added a leading slash to ALL relative links, like so:
     <img src="/images/button_1.jpg" /> and <form action="/search.asp" method="post">

Is there a modification I can make to IIS or IIRF so that I do NOT have to go into each web document and add a leading slash to all relative links?

Anything with a relative link is affected such as css, javascript, etc. Absolute paths are fine.
Oct 2, 2008 at 11:17 PM
Edited Oct 2, 2008 at 11:20 PM
got it.  Yes, i understand. 
Well. . .

Here's the deal:  when you rewrite the URL on the server side, the browser thinks the relative URLs are rooted at a location that is different than the actual location of the server script.
whoosh, that is hard to parse, let me see if I can explain.

Suppose you have a page, called page.asp.    It is reachable directly by tickling http://server/Page.asp.
Now, the normal (non search-engine-optimized) URLs that people will use to get to that page, look like so:  http://server/Page.asp?p1=v1&p2=v2

Where p1 = the name of query parameter #1
v1 = the value of query param #1

And you rewrite URLS on the server side, to allow something like this:
http://server/Kitchen/FryPans.htm   in the browser, instead of http://server/Page.asp?Department=Kitchen&ProductCategory=FryPans

now the thing that is running is Page.asp, and it thinks that it lives at the document root.  So, in the dynamic pages it generates, it emits URLs with a relative qualification, assuming that images/button1.jpg will resolve to http://server/images/button1.jpg.
If there is no rewrite, the browser agrees with this, and uses  http://server/images/button1.jpg.

But if there is a rewrite, then the Browser thinks the document is rooted at "Kitchen" in the URL space.  therefore it applies that prefix to every unqualified URL.  Ergo, http://server/Kitchen/images/button1.jpg.

This is done by the browser.  Not by your ASP nor by IIRF.   The browser does this because we have lied to the browser about the exact server-side location of the URL.

How to fix?
several ways:
1. make each relative URL non-relative.  This is what you were doing.
2. insert another rule in IIRF to "unmangle" those URLs.  So if you see /foo/images/something.jpg coming in from the browser (or css, or javascript, etc) , rewrite it to   /images/something.jpg.
3. Eliminate the directory skew between the requested and rewritten URL. 

For #3, what I mean is this: 

Suppose the URL in the browser is  http://server/Kitchen-Frypans.html
if you rewrite that to Page.asp?Dept=Kitchen&Product=FryPans, you haven't changed the directory of the URL. 
They are both at the top level.  Therefore the browser sees a toplevel directory, and when it applies the prefix to unqualified URLs in the document, (eg, <img src="images/button1.jpg">)  it will use the top-level directory root.    No skew.

Does that make sense?

Unfortunately, rewriting URLs does have some implications on how you construct your apps, especially around  unqualified URLs embedded in the docs.  

Oct 3, 2008 at 9:19 PM
Edited Oct 3, 2008 at 9:35 PM
Thanks, that helps a lot.

#2 would fix images on this one monstrous site I'm working on now, but I would still have to edit the relative hyperlinks.

From now on, I will try to use method 3 which would mean using another char besides a slash to separate parameters. Am I correct in thinking that the browser just translates each slash as a sub-directory? And is there no way to control what the browser sees as the server-location (document root) before serving up the ASP?

As a side question:
I'm sure you've had a lot of questions about SEO; and while I agree with IIRF for fixing SLOPPY URLs, for a cheap fast way to fix poor site design, me and my team are left wondering. Does this really help with SEO, or does it just make reports more readable. We get a lot of request because people want to improve their search rankings, usually in Google.
Oct 4, 2008 at 1:31 AM
Yes, you are correct - each slash in the URL is a directory to the browser.  You could use a dash character.  That is often safe. 

SEO works, yes.  But if you asked me for quantitative evidence, I don't have any.  It might be something you could investigate, then you'd be able to tell your customers "average 18% better page rank".
or whatever the number is.

For me, often the purpose of rewriting is URL beauty.  Honestly.  Sometimes it's just hard to remember a long parameterized URL.  A nice clean short on is often better.