Append /default.aspx and preserve querystring

Topics: Developer Forum, User Forum
May 21, 2010 at 12:44 PM

Hi  

 

I've tried and can't figure this out.  I've read loads of posts on various sites but none seem to point me in the right direction. 
My websites have URLs with various segments, and they appear on my pages like this:

http://mydomain/section1/subsection3/page2/

I rewrite them like this  

 

http://mydomain/section1/subsection3/page2/default.aspx

 

What I would like is for 

 

http://mydomain/section1/subsection3/page2/?randomparam1=somevalue

To rewrite to

http://mydomain/section1/subsection3/page2/default.aspx?randomparam1=somevalue

There can be any number of sections, subsections and pages, and therefore any number of segments to the URL.

There is nearly always a trailing "/", but they RegExp would need to check that.  

 

There may or may not be a querystring in the URL.

 

I'm currently using this:

 

RewriteCond %{REQUEST_FILENAME}\default\.aspx -f
RewriteRule ^(/[^.?/]+?)/*$ /$1/default.aspx [I,L]
RewriteRule ^(/[^.?]+?)/*$ $1/default.aspx [I,L]

 

Which works fine for URLS with no querystring.

 

Can this be done?  Can anyone help please?

 

Thanks in advance

 

Lee.

 

Coordinator
May 21, 2010 at 2:47 PM

Use the [QSA] option.

It appends any existing query string, to your specified replacement.

May 21, 2010 at 7:44 PM

OK, I'm using v1.2 at the moment, so I think I need to upgrade to use the QSA option.

I tried to run v2.x and had some problems.  It doesn't seem to like 64 bit servers.

That said, I had to manually install because for all the looking in the world, I can't find the MSI installer.  Where is it?

Coordinator
May 21, 2010 at 8:24 PM

The MSI installer for v2.0 is not available. 
The MSI installer for v2.1 is on the downloads page.

I don't think the 64-bit issue is any different for v2.1, than it was for v1.2.

 

May 21, 2010 at 9:24 PM
Yeah got it working manually now but having trouble with the actual syntax of the rule and condition. I tried adding [QSA] but I get a standard IIS 404, so asp.net is envoked.

Any ideas? What would the syntax be?

Thanks forquick response. If you can get this working I'll be donating!



On 21 May 2010, at 09:24 PM, "Cheeso" <notifications@codeplex.com> wrote:

From: Cheeso

The MSI installer for v2.0 is not available.
The MSI installer for v2.1 is on the downloads page.

I don't think the 64-bit issue is any different for v2.1, than it was for v1.2.

May 21, 2010 at 9:28 PM
And still can't find the installer. Where's the link?


On 21 May 2010, at 09:24 PM, "Cheeso" <notifications@codeplex.com> wrote:

From: Cheeso

The MSI installer for v2.0 is not available.
The MSI installer for v2.1 is on the downloads page.

I don't think the 64-bit issue is any different for v2.1, than it was for v1.2.

Coordinator
May 22, 2010 at 12:33 AM

http://iirf.codeplex.com/releases/view/36814

May 22, 2010 at 8:54 AM
Edited May 22, 2010 at 10:53 AM
Ok thanks. I wasn't looking in the beta version. Is it this version I need for the QSA to work?
There doesn't appear to be any QSA examples.
 
The aim is to make a url such as
 
rewrite to 
 
The number of segments in the URL and the names of the segments can be anything.
This is what I think shoud work based on what I've read:

RewriteCond %{REQUEST_FILENAME}\default\.aspx -f

RewriteRule ^(/[^.?/]+?)/*$ /$1/default.aspx [QSA,I,L]
RewriteRule ^(/[^.?]+?)/*$ $1/default.aspx [QSA,I,L]


 
But all I get is 404.  I don't think QSA is working.  I am using 2.1.1.20 which I understand is the correct version.
Can you help?



On 22 May 2010, at 01:33 AM, "Cheeso" <notifications@codeplex.com> wrote:

Coordinator
May 22, 2010 at 12:47 PM

can you explain what your regex does, piece by piece?

 

May 22, 2010 at 2:50 PM
I found it on a website somewhere. It made sense on the website when they explained it. If the incoming URL doesn't end in default.aspx the it adds it. It also looks for a traling / and adds if needed.
It works fine if there's no querystring.


On 22 May 2010, at 01:47 PM, "Cheeso" <notifications@codeplex.com> wrote:

From: Cheeso

can you explain what your regex does, piece by piece?

Coordinator
May 22, 2010 at 9:19 PM
Edited May 27, 2010 at 11:24 AM

It seems to me you have two rules.
The first rule has a condition attached to it.  I don't know why you would use a condition on one of those rules, and not the other.

If you want to append default.aspx to any URL then I would suggest something more like this:

RewriteRule ^/(?!\.aspx)([^\?]*)\??  /$1/default.aspx [QSA,I,L] 

That rule says, in English, any URL that does not contain a .aspx, will be replaced with a URL that has default.aspx appended. The (?!...) in the regex is a non-capturing negative lookahead. It says "match, as long as the pattern within parens does NOT match." The sole capture group is ([^?]*), which says "match zero or more characters, which are not question-mark". This captures everything up to but not including any question mark in the incoming URL. This is then available as $1 in the replacement string.

The pattern ends in \??; this matches the question mark, if one is present in the incoming URL. The \? is an escaped question-mark, and the following ? is a "zero or one" quantifier. The pattern neither matches on nor captures anything after the question mark that might be present in the incoming URL.

The replacement string includes the first capture group, which is everything in the incoming URL up to the first ? (if any). Then a slash, then default.aspx. Finally, via the QSA modifier, the rule appends any query string that appears on the input to the replacement result.

Examples

incoming replacement
/foo /foo/default.aspx
/foo? /foo/default.aspx?
/foo?arf /foo/default.aspx?arf
/foo/ /foo//default.aspx
/foo/?arf /foo//default.aspx?arf

Whoops! There are double-slashes in those last two.  But you said you wanted to append a slash only when it isn't present. To do that you'll need to adjust the rule a little.

RewriteRule ^/(?!\.aspx)([^\?]*)(?<!/)(/?)\??  /$1/default.aspx [QSA,I,L]

This captures two subgroups. The 1st subbgroup, which is accessible via $1 in the replacement string, works as above - it captures a zet of zero or more characters that are not question mark. But, there's a negative lookbehind denoted by (?<!..) that says "only if the final character is not a slash". The second subgroup, accessible via $2 in the replacement string, captures the final slash, if it is present. The ? in the sequence /? is a quantifier, and implies zero or one of the previous element, the slash. Following that is the same \?? from the prior rule, which matches the question mark if it is present. The replacement string never references $2 - the slash. The point of capturing it is to just remove it, if it is present.

Examples

incoming replacement
/foo /foo/default.aspx
/foo? /foo/default.aspx?
/foo?arf /foo/default.aspx?arf
/foo/ /foo/default.aspx
/foo/?arf /foo/default.aspx?arf

Some additional comments:  If you want the condition (the RewriteCond) on that rule, you can apply it yourself. You may or may not want to include the negative lookahead that rejects any URl with .aspx in it already.  You may want to use some other negative lookahead.  Depending on where the rule lies in your ini file, relative to other rules, it may not be necessary at all. 

There's one final thing - you need to handle the edge case where the URL is just / . For that, add this rule:

RewriteRule ^/\??                              /default.aspx [QSA,I,L]

This one says, if the incoming URL is empty, just a slash followed by *maybe* a question mark, then rewrite to /default.aspx.  I tested all this out with the TestDriver.exe tool. (It's broken in the v2.1.1.20, but it will be fixed in IIRF v2.1.1.21.)

May 25, 2010 at 6:57 PM
Thanks Cheeso.  Looking forward to the new version.
 
Regards
 
Lee.

On Sat, May 22, 2010 at 10:19 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

It seems to me you have two rules.
The first rule has a condition attached to it.  I don't know why you would use a condition on one of those rules, and not the other.

If you want to append default.aspx to any URL then I would suggest something more like this:

RewriteRule ^/(?!\.aspx)([^\?]*)\??  /$1/default.aspx [QSA,I,L] 

That rule says, in English, any URL that does not contain a .aspx, will be replaced with a URL that has default.aspx appended. The (?!...) in the regex is a non-capturing negative lookahead. It says "match, as long as the pattern within parens does NOT match." The sole capture group is ([^?]*), which says "match zero or more characters, which are not question-mark". This captures everything up to but not including any question mark in the incoming URL. This is then available as $1 in the replacement string.

The pattern ends in \??; this matches the question mark, if one is present in the incoming URL. The \? is an escaped question-mark, and the following ? is a "zero or one" quantifier. The pattern neither matches on nor captures anything after the question mark that might be present in the incoming URL.

The replacement string includes the first capture group, which is everything in the incoming URL up to the first ? (if any). Then a slash, then default.aspx. Finally, via the QSA modifier, the rule appends any query string that appears on the input to the replacement result.

Examples

incoming replacement
/foo /foo/default.aspx
/foo? /foo/default.aspx?
/foo?arf /foo/default.aspx?arf
/foo/ /foo//default.aspx
/foo/?arf /foo//default.aspx?arf

But you want something a little different. You want to append a slash only when it isn't present. To do that you'll need to adjust the rule a little.

RewriteRule ^/(?!\.aspx)([^\?]*(?<!--)(/?)\??  /$1/default.aspx [QSA,I,L]

This captures two subgroups. The 1st subbgroup, which is accessible via $1 in the replacement string, captures everything up to but not including the final slash, if any. The second subgroup, accessible via $2 in the replacement string, captures the final slash, if it is present. The ? in the sequence /? is a quantifier, and implies zero or one of the previous element, the slash. Following that is the same \?? from the prior rule, which matches the question mark if it is present. The replacement string never references $2 - the slash. The point of capturing it is to just remove it, if it is present.

Examples

incoming replacement
/foo /foo/default.aspx
/foo? /foo/default.aspx?
/foo?arf /foo/default.aspx?arf
/foo/ /foo/default.aspx
/foo/?arf /foo/default.aspx?arf

If you want the condition (the RewriteCond) on that rule, you can apply it yourself.

There's one final thing - you need to handle the edge case where the URL is just / . For that, add this rule:

RewriteRule ^/\??                              /default.aspx [QSA,I,L]

I tested all this out with the TestDriver.exe tool. It's broken in the v2.1.1.20, but it will be fixed in IIRF v2.1.1.21.

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Coordinator
May 25, 2010 at 9:20 PM
IIRF V2.1.1.21 is available now.
May 25, 2010 at 11:30 PM
Thanks Cheeso
 
I tried it out with your regexp, and it seems to partially work.  The problem is that requests for .js files, images etc are all being rewritten.
 
My previous rules only appended ".aspx" to pages only.
 
Please help
 
Lee.
 
 


 
On Tue, May 25, 2010 at 10:20 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

IIRF V2.1.1.21 is available now.

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Coordinator
May 26, 2010 at 12:39 AM

Well - the regex and rule that I gave to you, applies only to those URLs that ARE NOT .aspx.  In other words it excludes .aspx URLs from being rewritten.

If you also want to exclude .js URLs and .css URLs, then you'll have to specify those exclusions in the rule and the pattern.

 

 

May 27, 2010 at 9:00 AM
That's interesting.  Looking at my original two rules (that I am currently using)
 

RewriteCond %{REQUEST_FILENAME}\default\.aspx -f

RewriteRule ^(/[^.?/]+?)/*$ /$1/default.aspx [I,L]
RewriteRule ^(/[^.?]+?)/*$ $1/default.aspx [I,L]

I must admit, I don't know what the RewriteCond does, or why it's there.  The whole thing was given to me by another kind person who offered to help me out.

So my current rules don't say "apply only if it's not a .aspx page", and I don't have a problem with .js and .css files being rewritten.  It all works fine.  It only rewrites where the URL ends in a segment with or without a trailing "/".  I just can't get it to rewrite "default.aspx" after the last "/" and then do the QSA.

Could something along these lines be combined with your solution to make this work for just URLS ending in a segment with or without a trailing "/"?

Thanks

Lee.

 

 


 
On Wed, May 26, 2010 at 1:39 AM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

Well - the regex and rule that I gave to you, applies only to those URLs that ARE NOT .aspx.  In other words it excludes .aspx URLs from being rewritten.

If you also want to exclude .js URLs and .css URLs, then you'll have to specify those exclusions in the rule and the pattern.

 

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Coordinator
May 27, 2010 at 11:24 AM

Your current rule says "apply only if there's no dot in the incoming URL request." This is a modification of the suggestion from above to work like that:

RewriteRule ^/([^.?]*)(?<!/)(/?)\??  /$1/default.aspx [QSA,L]
RewriteRule ^/\??                    /default.aspx [QSA,L]

You probably don't need the RewriteCond.

May 27, 2010 at 11:37 AM
Thanks.  Would that rule apply if a value being passed in the querystring contained a dot?
 
Lee.

On Thu, May 27, 2010 at 12:24 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

Your current rule says "apply only if there's no dot in the incoming URL request." This is a modification of the suggestion from above to work like that:

RewriteRule ^/([^.?]*)(?<!/)(/?)\??  /$1/default.aspx [QSA,L]
RewriteRule ^/\??                    /default.aspx [QSA,L]

You probably don't need the RewriteCond.

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


May 27, 2010 at 8:16 PM
I tried your latest suggestion.
 
 
 
I can't work out why.  Please can you help?
 
Lee.
 
 
 
 

 
On Thu, May 27, 2010 at 12:37 PM, Lee Wilson <lee@lwnet.co.uk> wrote:
Thanks.  Would that rule apply if a value being passed in the querystring contained a dot?
 
Lee.

On Thu, May 27, 2010 at 12:24 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

Your current rule says "apply only if there's no dot in the incoming URL request." This is a modification of the suggestion from above to work like that:

RewriteRule ^/([^.?]*)(?<!/)(/?)\??  /$1/default.aspx [QSA,L]
RewriteRule ^/\??                    /default.aspx [QSA,L]

You probably don't need the RewriteCond.

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com



Coordinator
May 27, 2010 at 11:42 PM

Sorry, I'm out of ideas.  There's nothing in the rules that would rewrite to logo.aspx, as you can see.
Something else is doing that.

Check the IIRF log to gain more insight.

 

 

May 28, 2010 at 9:18 AM
More info.
 
using these rules:

RewriteRule ^/(?!\*.gif)([^\?]*)\?? /$1/default.aspx [QSA,I,L]
RewriteRule ^/?? /default.aspx [QSA,L]

The URL

http://mydomain/SiteStyles/Default/images/logo.gif

is rewritten to



http://mydomain/SiteStyles/Default/images/logo.gif/default.aspx

I can promise you nothing else is doing this!

 

Lee.

 

 

 

 

 

On Fri, May 28, 2010 at 12:42 AM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

Sorry, I'm out of ideas.  There's nothing in the rules that would rewrite to logo.aspx, as you can see.
Something else is doing that.

Check the IIRFlog to gain more insight.

 

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


May 28, 2010 at 10:30 AM
I've gone back to this idea youe suggested:
 

RewriteRule ^/(?!\.aspx)([^\?]*(?<!--)(/?)\?? /$1/default.aspx [QSA,I,L]

RewriteRule ^/\?? /default.aspx [QSA,L]

It seems that if you comment out the second rule, nothing happens at all, so it looks like only the second rule is doing anything.  And it appends "/default.aspx" after everything, even if the url ends in /image.gif or /styles.css for example.
 
Lee.
 
 


On Fri, May 28, 2010 at 10:17 AM, Lee Wilson <lee@lwnet.co.uk> wrote:
More info.
 
using these rules:

RewriteRule ^/(?!\*.gif)([^\?]*)\?? /$1/default.aspx [QSA,I,L]

RewriteRule ^/?? /default.aspx [QSA,L]

The URL

is rewritten to



http://mydomain/SiteStyles/Default/images/logo.gif/default.aspx

I can promise you nothing else is doing this!

 

Lee.

 

 

 

 

 

On Fri, May 28, 2010 at 12:42 AM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

Sorry, I'm out of ideas.  There's nothing in the rules that would rewrite to logo.aspx, as you can see.
Something else is doing that.

Check the IIRFlog to gain more insight.

 

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com



Coordinator
May 28, 2010 at 3:57 PM

ah, there's something wrong with your first rule. Some automatic HTML escaping must have happened, with those angle brackets, because that's not the rule I suggested.

In the forums, scroll back up and you can see the one I suggested.

Also, I explained in that post the purpose of both rules.

May 28, 2010 at 9:16 PM
Hi Cheeso
 
I am definately using this:

RewriteRule ^/(?!\.aspx)([^\?]*(?<!--)(/?)\?? /$1/default.aspx [QSA,I,L]

RewriteRule ^/\?? /default.aspx [QSA,I,L]

All requests are rewritten to the site roos=t, ie http://mydomain/default.aspx
 
I don't see any deviation from your example.  Are you sure it can't be a but in this release?
 
Lee.
 
 


On Fri, May 28, 2010 at 4:57 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

ah, there's something wrong with your first rule. Some automatic HTML escaping must have happened, with those angle brackets, because that's not the rule I suggested.

In the forums, scroll back up and you can see the one I suggested.

Also, I explained in that post the purpose of both rules.

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Coordinator
May 29, 2010 at 10:28 AM

I'm reading this in the forums, and what's displayed in your message is not the same as anything in any of my messages.

There is a spurious <!-- in the rule in your message .  I'm not sure when that crept in there.  It shouldn't be there.

If you use the forums you can click the "code" button and embed your rules in there, and they won't be disturbed.

 

 

 

May 29, 2010 at 12:48 PM
Yes,OK I see that.  So I copied the code directly from the forum and tried it.  A slight improvement I think.  But it still rewrites .js and .css files.
 
For example, if I change the rule to

RewriteRule ^/(?!\.js)([^\?]*)(?<!/)(/?)\?? /$1/default.aspx [QSA,I,L]

and browse to
 
it gets rewritten to
 
What is wrong with the exclusion rule?  All I did was change aspx to js.  Logically that should prevent .js URLs from being rewritten.
 
Lee.

On Sat, May 29, 2010 at 11:28 AM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

I'm reading this in the forums, and what's displayed in your message is not the same as anything in any of my messages.

There is a spurious <!-- in the rule in your message .  I'm not sure when that crept in there.  It shouldn't be there.

If you use the forums you can click the "code" button and embed your rules in there, and they won't be disturbed.

 

 

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Coordinator
May 29, 2010 at 3:25 PM

Right.  The suggestion I made Thursday would address that.  (We already had this conversation.)

 

May 30, 2010 at 10:39 AM
I tried that one again, making sure I copied the code from the forum page to prevent any unwanted escaping.
 
Same thing.  It rewrites everything, regardless of what the rule says.
 
There's either something wrong with the rule, or the filter is not understanding the rule properly.
 
What to do you think?
 
Lee.
 
 


 
On Sat, May 29, 2010 at 4:25 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

Right.  The suggestion I made Thursday would address that.  (We already had this conversation.)

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Coordinator
May 30, 2010 at 2:36 PM

I think you should look in the IIRF log file to diagnose it.

 

May 30, 2010 at 3:59 PM
Nothing is being written to the logfile.
Permissions are OK, I've granted full access to Everyone.

On Sun, May 30, 2010 at 3:36 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

I think you should look in the IIRF log file to diagnose it.

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Coordinator
May 30, 2010 at 5:40 PM

You will need to go through the troubleshooting and verification steps, in the documentation.

 

May 31, 2010 at 1:17 PM
OK done that.
 
No issues or errors reported on the StatusEnquiry page.  Everything looks good.  However, nothing is logged in the log file.  The event viewer said the logfile doesn't exist.  So I manually created it, gave full access permissions to everyone for that file.  Still nothing.
 
If I can't get the logfile to work, how else can I figure out what is wrong?

On Sun, May 30, 2010 at 6:40 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

You will need to go through the troubleshooting and verification steps, in the documentation.

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Coordinator
May 31, 2010 at 1:38 PM

To diagnose rules, you need the logfile.

If there is an event in the event log regarding the log file, there will be an error code. The error code indicates why the logfile was not created.  (This is in the "troubleshooting" page in the documentation. )

In most cases the problem is a permissions issue. 

Remember the RewriteLog directive specifies a stub, not a logfile name.  Check the documentation on that directive if you're not clear on that.

 

 

 

May 31, 2010 at 2:34 PM

RewriteRule ^/([^.?]*)(?OK Logfile working now.  I don't know why because I made no changes to anything.Anyway, the logfile shows this:

Mon May 31 14:09:04 -  7836 - DoRewrites: Url (no decoding): '/sitestyles/default/images/icons/48/Twitter_48x48.png'
Mon May 31 14:09:04 -  7836 - EvaluateRules: depth=0
Mon May 31 14:09:04 -  7836 - EvaluateRules: no RewriteBase
Mon May 31 14:09:04 -  7272 - HttpFilterProc: SF_NOTIFY_URL_MAP
Mon May 31 14:09:04 -  7272 - HttpFilterProc: cfg= 0x1BBBDC68
Mon May 31 14:09:04 -  7836 - EvaluateRules: Rule 1: -1 (No match)
Mon May 31 14:09:04 -  7836 - EvaluateRules: Rule 2: 3 matches
Mon May 31 14:09:04 -  7836 - EvaluateRules: Result (length 62): /sitestyles/default/images/icons/48/Twitter_48x48/default.aspx
Mon May 31 14:09:04 -  7836 - EvaluateRules: Last Rule
Mon May 31 14:09:04 -  7836 - EvaluateRules: returning 1
Mon May 31 14:09:04 -  7836 - DoRewrites: Rewrite Url to: '/sitestyles/default/images/icons/48/Twitter_48x48/default.aspx'

So you can see, it seems to be removing the .fileExtension, and appending "/default.aspx".  It's doing this to all URLs.

I only want it to do it to URLs that end in a vdir name such as http://mydomain/login or http://mydomain/login/

The rules I am using are

RewriteRule (.+\.)(ashx)$   -   [L]

RewriteRule ^/([^.?]*)(?<!/)(/?)\??  /$1/default.aspx [QSA,L]

RewriteRule ^/\??                    /default.aspx [QSA,L]

 

The first rule won't be causing the problem here.

May 31, 2010 at 3:12 PM

Just to be sure I ran it with just the two rules you suggested, abnd got this:

Mon May 31 16:09:11 -  3520 - DoRewrites: Url (no decoding): '/SiteStyles/Default/images/logo.gif'
Mon May 31 16:09:11 -  3520 - EvaluateRules: depth=0
Mon May 31 16:09:11 -  3520 - EvaluateRules: no RewriteBase
Mon May 31 16:09:11 -  3520 - EvaluateRules: Rule 1: 3 match
Mon May 31 16:09:11 -  3520 - EvaluateRules: Result (length 44): /SiteStyles/Default/images/logo/default.aspx
Mon May 31 16:09:11 -  3520 - EvaluateRules: Last Rule
Mon May 31 16:09:11 -  3520 - EvaluateRules: returning 1
Mon May 31 16:09:11 -  3520 - DoRewrites: Rewrite Url to: '/SiteStyles/Default/images/logo/default.aspx'
Mon May 31 16:09:11 -  3520 - HttpFilterProc: SF_NOTIFY_URL_MAP
Mon May 31 16:09:11 -  3520 - HttpFilterProc: cfg= 0x01587FB8
Mon May 31 16:09:11 -  4264 - HttpFilterProc: SF_NOTIFY_LOG

Coordinator
May 31, 2010 at 3:22 PM

Ahhhhh!!   A log file.  Well this makes things easier.  Yes, you're right.  The 2nd rule is the one that is matching. Very clear.  My mistake.

So let's see, the thing we were trying to catch with that second rule was... a URL with no path, just a query string. In other words, just / , or /?something .

As the rule is, it matches everything.  My mistake for suggesting it.  I think you could get what you want with something like this:

RewriteRule ^/(\?|$)                 /default.aspx [QSA,L]

That pattern matches either / followed by $, implying end-of-line, or / followed by a question mark, implying a query string.

May 31, 2010 at 3:46 PM
I think we're getting there.  If I use that rule only, it works for the homepage, and the js and css files are not rewritten.
 
However, for a URL with n number of segments, it doesn't work.  I get a standard IIS 404 message.
 
Any ideas?

On Mon, May 31, 2010 at 4:22 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

Ahhhhh!!   A log file.  Well this makes things easier.  Yes, you're right.  The 2nd rule is the one that is matching. Very clear.  My mistake.

So let's see, the thing we were trying to catch with that second rule was... a URL with no path, just a query string. In other words, just / , or /?something .

As the rule is, it matches everything.  My mistake for suggesting it.  I think you could get what you want with something like this:

RewriteRule ^/(\?|$)                 /default.aspx [QSA,L]

That pattern matches either / followed by $, implying end-of-line, or / followed by a question mark, implying a query string.

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Coordinator
May 31, 2010 at 3:56 PM

No, I don't have any ideas - you need to show me the log file.  Also can you confirm that you are still using 2 rules.  That rule i just covers the edge condition - it is intended to catch only the case where the URL has no URL path, with or without a query string.  The first rule is intended to catch other URLs, with one or more segments in the URL path.  Are you using both rules?  or, I guess, all three rules.

RewriteRule (.+\.)(ashx)$   -   [L]
RewriteRule ^/([^.?]*)(?<!/)(/?)\??  /$1/default.aspx [QSA,L]
RewriteRule ^/(\?|$)                  /default.aspx [QSA,L]

if so, post the logfile excerpt that shows the URL that is not being handled the way you think it should.  like last time.

May 31, 2010 at 7:04 PM
OK here we have two log snippets.  The first is when we browse the site root.   As you can see it successfully rewrites to /default.aspx, however the CSS and JS files etc are also rewritten.  There are other files I also do not want rewritten, for example there are handlers for displaying images.  I theory, if the rule only allows a vdir name with or without a trailing "/", and there can be n number of URL segments, then that should be all that's needed.  Anything else will not match the rule, and therefore will just not be rewritten.
 
Here are the rules
 
RewriteRule (.+\.)(ashx)$   -   [L]
RewriteRule ^/([^.?]*)(?<!/)(/?)\??  /$1/default.aspx [QSA,L]
RewriteRule ^/(\?|$)                 /default.aspx [QSA,L]
 
Here are the logs:
 
Mon May 31 19:53:33 -  9908 - DoRewrites: Url (no decoding): '/'
Mon May 31 19:53:33 -  9908 - EvaluateRules: depth=0
Mon May 31 19:53:33 -  9908 - EvaluateRules: no RewriteBase
Mon May 31 19:53:33 -  9908 - EvaluateRules: Rule 1: -1 (No match)
Mon May 31 19:53:33 -  9908 - EvaluateRules: Rule 2: -1 (No match)
Mon May 31 19:53:33 -  9908 - EvaluateRules: Rule 3: 2 matches
Mon May 31 19:53:33 -  9908 - EvaluateRules: Result (length 13): /default.aspx
Mon May 31 19:53:33 -  9908 - EvaluateRules: Last Rule
Mon May 31 19:53:33 -  9908 - EvaluateRules: returning 1
Mon May 31 19:53:33 -  9908 - DoRewrites: Rewrite Url to: '/default.aspx'
 
 
Mon May 31 19:48:44 - 10000 - DoRewrites: Url (no decoding): '/sitestyles/default/images/icons/48/FaceBook_48x48.png'
Mon May 31 19:48:44 - 10000 - EvaluateRules: depth=0
Mon May 31 19:48:44 - 10000 - EvaluateRules: no RewriteBase
Mon May 31 19:48:44 - 10000 - EvaluateRules: Rule 1: -1 (No match)
Mon May 31 19:48:44 - 10000 - EvaluateRules: Rule 2: 3 matches
Mon May 31 19:48:44 - 10000 - EvaluateRules: Result (length 63): /sitestyles/default/images/icons/48/FaceBook_48x48/default.aspx
Mon May 31 19:48:44 - 10000 - EvaluateRules: Last Rule
Mon May 31 19:48:44 - 10000 - EvaluateRules: returning 1
Mon May 31 19:48:44 - 10000 - DoRewrites: Rewrite Url to: '/sitestyles/default/images/icons/48/FaceBook_48x48/default.aspx'
 
 
As always, much appreciated
 
Lee.
Coordinator
May 31, 2010 at 7:23 PM

ah, yes, ok.  Same problem as before.

That 2nd rule needs to be adjusted.

Try this.

RewriteRule (.+\.)(ashx)$                   -                 [L]
RewriteRule ^/([^.?]*)(?<!/)(/\?|\?|/$|$)   /$1/default.aspx  [QSA,L]
RewriteRule ^/(\?|$)                        /default.aspx     [QSA,L]

 

That ought to be a little closer to what you want.

May 31, 2010 at 7:45 PM
I think you've cracked it!
 
Thanks Cheeso!

On Mon, May 31, 2010 at 8:23 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

ah, yes, ok.  Same problem as before.

That 2nd rule needs to be adjusted.

Try this.

RewriteRule (.+\.)(ashx)$                   -                 [L]
RewriteRule ^/([^.?]*)(?<!/)(/\?|\?|/$|$)   /$1/default.aspx  [QSA,L]
RewriteRule ^/(\?|$)                        /default.aspx     [QSA,L]

 

That ought to be a little closer to what you want.

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Coordinator
May 31, 2010 at 9:02 PM

Whew!  finally!

May 31, 2010 at 9:26 PM
Yeah, except now the damn thing won't run on my production server!
 
It's probably permissions, but I've been through the installation process 3 times now, and I'm certain I've given enough permissions to everything.
 
What's the most commonly missed thing?
 


 
On Mon, May 31, 2010 at 10:02 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

Whew!  finally!

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Coordinator
May 31, 2010 at 9:41 PM

You're not gonna believe this, but.. .the most common problem is...

Permissions.

The two main things are: that IIRF.ini can be read, and that the IIRF log file can be written.  Check the event log.  Verify that the argument provided to the RewriteLog directive is correct. 

If you hve the first problem, IIRF will do nothing.  Not even /iirfstatus will work.  If you have the 2nd problem (can't create logfile), then IIRF will work, and will respond to /iirfstatus, but it will not create a logfile.   

A tricky problem occurs when you move the ini file from some other location to the physical directory for the vdir.

Normally the physical directory of the vdir has an ACL that means any file you create will get permissions that allows IIS to read the file. But if you move a file into the directory, it brings its existing ACL with it, and doesn't get the ACL for a new file. 

Another common problem is that the directory that will eventually contain the IIRF log file, does not allow IIS to write there, or that there's a typo in the RewriteLog directive.

For diagnosing these permissions problems, icacls.exe is invaluable.  You should have it on your server. I think it's installed on all Windows servers now.

 

May 31, 2010 at 9:52 PM
OK, well that's enough for today, I'll continue the battle tomorrow.
 
FYI, the rewrite seemed to work on the first URL request of a new browser session.   After that, any subsequent requests are all 404s.
 
Weird.
 
Lee.

On Mon, May 31, 2010 at 10:41 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

You're not gonna believe this, but.. .the most common problem is...

Permissions.

The two main things are: that IIRF.ini can be read, and that the IIRF log file can be written.  Check the event log.  Verify that the argument provided to the RewriteLog directive is correct. 

If you hve the first problem, IIRF will do nothing.  Not even /iirfstatus will work.  If you have the 2nd problem (can't create logfile), then IIRF will work, and will respond to /iirfstatus, but it will not create a logfile.   

A tricky problem occurs when you move the ini file from some other location to the physical directory for the vdir.

Normally the physical directory of the vdir has an ACL that means any file you create will get permissions that allows IIS to read the file. But if you move a file into the directory, it brings its existing ACL with it, and doesn't get the ACL for a new file. 

Another common problem is that the directory that will eventually contain the IIRF log file, does not allow IIS to write there, or that there's a typo in the RewriteLog directive.

For diagnosing these permissions problems, icacls.exe is invaluable.  You should have it on your server. I think it's installed on all Windows servers now.

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Jun 1, 2010 at 9:38 AM
Additional (sorry), as soon as I switched back to IsapiRewrite4.dll, all the stangeness immedately stopped.
 
Lee.

On Tue, Jun 1, 2010 at 10:37 AM, Lee Wilson <lee@lwnet.co.uk> wrote:
FYI, I have reverted to the previous IsapiRewrite4.dll, which works, but I don't have the QSA functionality.
 
Lee.

On Tue, Jun 1, 2010 at 10:34 AM, Lee Wilson <lee@lwnet.co.uk> wrote:
Right, had another go today.
 
Pretty much the same as yesterday.  I'm certain permissions are OK, in fact I've probably given more than is necessary.  I have the DLL,, the .ini files, and the logfile all setup properly.  Here's what happens.
 
The live site (http://bandbase.co.uk) will load.  Then if you click on any link, you get a standard IIS 404.  Not an ASP.Net 404.  So it looks like the filter doesn't work on subsequest requests, or it would have sent the request through the ASP.Net engine.  The initial page that was requested immediately after resetting IIS works, but nothing else.  
 
Also, if the initial page you load is not the homepage, it will load once, and then a refresh gives a 404.
 
These behaviours are only reset when I reset IIS.  Then it will happen again for the next initial page I try to load, and so on.
 
Surely this cannot be a permissions problem?  I'm getting logs, they look good, like the previous ones I sent you.
 
Also, if I browse to http://bandbase.co.uk/iirfstatus after resetting IIS, I get the status page with no errors.  I did have to put "StatusInquiry ON /IirfStatus.htm RemoteOk" in the .ini file to make the status page work.
 
None of this happens on my development PC.
 
What could be causing this?
 
 
The production server is Win2003 32 bit.
 
Thanks

Lee.
 
 
 
 


 
On Mon, May 31, 2010 at 10:52 PM, Lee Wilson <lee@lwnet.co.uk> wrote:
OK, well that's enough for today, I'll continue the battle tomorrow.
 
FYI, the rewrite seemed to work on the first URL request of a new browser session.   After that, any subsequent requests are all 404s.
 
Weird.
 
Lee.

On Mon, May 31, 2010 at 10:41 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

You're not gonna believe this, but.. .the most common problem is...

Permissions.

The two main things are: that IIRF.ini can be read, and that the IIRF log file can be written.  Check the event log.  Verify that the argument provided to the RewriteLog directive is correct. 

If you hve the first problem, IIRF will do nothing.  Not even /iirfstatus will work.  If you have the 2nd problem (can't create logfile), then IIRF will work, and will respond to /iirfstatus, but it will not create a logfile.   

A tricky problem occurs when you move the ini file from some other location to the physical directory for the vdir.

Normally the physical directory of the vdir has an ACL that means any file you create will get permissions that allows IIS to read the file. But if you move a file into the directory, it brings its existing ACL with it, and doesn't get the ACL for a new file. 

Another common problem is that the directory that will eventually contain the IIRF log file, does not allow IIS to write there, or that there's a typo in the RewriteLog directive.

For diagnosing these permissions problems, icacls.exe is invaluable.  You should have it on your server. I think it's installed on all Windows servers now.

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com





Jun 1, 2010 at 9:40 AM
Right, had another go today.
 
Pretty much the same as yesterday.  I'm certain permissions are OK, in fact I've probably given more than is necessary.  I have the DLL,, the .ini files, and the logfile all setup properly.  Here's what happens.
 
The live site (http://bandbase.co.uk) will load.  Then if you click on any link, you get a standard IIS 404.  Not an ASP.Net 404.  So it looks like the filter doesn't work on subsequest requests, or it would have sent the request through the ASP.Net engine.  The initial page that was requested immediately after resetting IIS works, but nothing else.  
 
Also, if the initial page you load is not the homepage, it will load once, and then a refresh gives a 404.
 
These behaviours are only reset when I reset IIS.  Then it will happen again for the next initial page I try to load, and so on.
 
Surely this cannot be a permissions problem?  I'm getting logs, they look good, like the previous ones I sent you.
 
Also, if I browse to http://bandbase.co.uk/iirfstatus after resetting IIS, I get the status page with no errors.  I did have to put "StatusInquiry ON /IirfStatus.htm RemoteOk" in the .ini file to make the status page work.
 
None of this happens on my development PC.
 
What could be causing this?
 
 
The production server is Win2003 32 bit.
 
Thanks

Lee.
 
 
 
 


 
On Mon, May 31, 2010 at 10:52 PM, Lee Wilson <lee@lwnet.co.uk> wrote:
OK, well that's enough for today, I'll continue the battle tomorrow.
 
FYI, the rewrite seemed to work on the first URL request of a new browser session.   After that, any subsequent requests are all 404s.
 
Weird.
 
Lee.

On Mon, May 31, 2010 at 10:41 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

You're not gonna believe this, but.. .the most common problem is...

Permissions.

The two main things are: that IIRF.ini can be read, and that the IIRF log file can be written.  Check the event log.  Verify that the argument provided to the RewriteLog directive is correct. 

If you hve the first problem, IIRF will do nothing.  Not even /iirfstatus will work.  If you have the 2nd problem (can't create logfile), then IIRF will work, and will respond to /iirfstatus, but it will not create a logfile.   

A tricky problem occurs when you move the ini file from some other location to the physical directory for the vdir.

Normally the physical directory of the vdir has an ACL that means any file you create will get permissions that allows IIS to read the file. But if you move a file into the directory, it brings its existing ACL with it, and doesn't get the ACL for a new file. 

Another common problem is that the directory that will eventually contain the IIRF log file, does not allow IIS to write there, or that there's a typo in the RewriteLog directive.

For diagnosing these permissions problems, icacls.exe is invaluable.  You should have it on your server. I think it's installed on all Windows servers now.

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com



Jun 1, 2010 at 9:42 AM
FYI, I have reverted to the previous IsapiRewrite4.dll, which works, but I don't have the QSA functionality.
 
Lee.

On Tue, Jun 1, 2010 at 10:34 AM, Lee Wilson <lee@lwnet.co.uk> wrote:
Right, had another go today.
 
Pretty much the same as yesterday.  I'm certain permissions are OK, in fact I've probably given more than is necessary.  I have the DLL,, the .ini files, and the logfile all setup properly.  Here's what happens.
 
The live site (http://bandbase.co.uk) will load.  Then if you click on any link, you get a standard IIS 404.  Not an ASP.Net 404.  So it looks like the filter doesn't work on subsequest requests, or it would have sent the request through the ASP.Net engine.  The initial page that was requested immediately after resetting IIS works, but nothing else.  
 
Also, if the initial page you load is not the homepage, it will load once, and then a refresh gives a 404.
 
These behaviours are only reset when I reset IIS.  Then it will happen again for the next initial page I try to load, and so on.
 
Surely this cannot be a permissions problem?  I'm getting logs, they look good, like the previous ones I sent you.
 
Also, if I browse to http://bandbase.co.uk/iirfstatus after resetting IIS, I get the status page with no errors.  I did have to put "StatusInquiry ON /IirfStatus.htm RemoteOk" in the .ini file to make the status page work.
 
None of this happens on my development PC.
 
What could be causing this?
 
 
The production server is Win2003 32 bit.
 
Thanks

Lee.
 
 
 
 


 
On Mon, May 31, 2010 at 10:52 PM, Lee Wilson <lee@lwnet.co.uk> wrote:
OK, well that's enough for today, I'll continue the battle tomorrow.
 
FYI, the rewrite seemed to work on the first URL request of a new browser session.   After that, any subsequent requests are all 404s.
 
Weird.
 
Lee.

On Mon, May 31, 2010 at 10:41 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

You're not gonna believe this, but.. .the most common problem is...

Permissions.

The two main things are: that IIRF.ini can be read, and that the IIRF log file can be written.  Check the event log.  Verify that the argument provided to the RewriteLog directive is correct. 

If you hve the first problem, IIRF will do nothing.  Not even /iirfstatus will work.  If you have the 2nd problem (can't create logfile), then IIRF will work, and will respond to /iirfstatus, but it will not create a logfile.   

A tricky problem occurs when you move the ini file from some other location to the physical directory for the vdir.

Normally the physical directory of the vdir has an ACL that means any file you create will get permissions that allows IIS to read the file. But if you move a file into the directory, it brings its existing ACL with it, and doesn't get the ACL for a new file. 

Another common problem is that the directory that will eventually contain the IIRF log file, does not allow IIS to write there, or that there's a typo in the RewriteLog directive.

For diagnosing these permissions problems, icacls.exe is invaluable.  You should have it on your server. I think it's installed on all Windows servers now.

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com




Jun 1, 2010 at 10:38 AM
Cheeso, I decided to use the installer (wish I had done so earlier), and it works fine now.
 
I cannot for the life of me work out what is different here.  Only think I can think of is that the DLL was somehow corrupt?
 
Anyway, very happy now!
 
Lee.
 


 
On Tue, Jun 1, 2010 at 10:38 AM, Lee Wilson <lee@lwnet.co.uk> wrote:
Additional (sorry), as soon as I switched back to IsapiRewrite4.dll, all the stangeness immedately stopped.
 
Lee.

On Tue, Jun 1, 2010 at 10:37 AM, Lee Wilson <lee@lwnet.co.uk> wrote:
FYI, I have reverted to the previous IsapiRewrite4.dll, which works, but I don't have the QSA functionality.
 
Lee.

On Tue, Jun 1, 2010 at 10:34 AM, Lee Wilson <lee@lwnet.co.uk> wrote:
Right, had another go today.
 
Pretty much the same as yesterday.  I'm certain permissions are OK, in fact I've probably given more than is necessary.  I have the DLL,, the .ini files, and the logfile all setup properly.  Here's what happens.
 
The live site (http://bandbase.co.uk) will load.  Then if you click on any link, you get a standard IIS 404.  Not an ASP.Net 404.  So it looks like the filter doesn't work on subsequest requests, or it would have sent the request through the ASP.Net engine.  The initial page that was requested immediately after resetting IIS works, but nothing else.  
 
Also, if the initial page you load is not the homepage, it will load once, and then a refresh gives a 404.
 
These behaviours are only reset when I reset IIS.  Then it will happen again for the next initial page I try to load, and so on.
 
Surely this cannot be a permissions problem?  I'm getting logs, they look good, like the previous ones I sent you.
 
Also, if I browse to http://bandbase.co.uk/iirfstatus after resetting IIS, I get the status page with no errors.  I did have to put "StatusInquiry ON /IirfStatus.htm RemoteOk" in the .ini file to make the status page work.
 
None of this happens on my development PC.
 
What could be causing this?
 
 
The production server is Win2003 32 bit.
 
Thanks

Lee.
 
 
 
 


 
On Mon, May 31, 2010 at 10:52 PM, Lee Wilson <lee@lwnet.co.uk> wrote:
OK, well that's enough for today, I'll continue the battle tomorrow.
 
FYI, the rewrite seemed to work on the first URL request of a new browser session.   After that, any subsequent requests are all 404s.
 
Weird.
 
Lee.

On Mon, May 31, 2010 at 10:41 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

You're not gonna believe this, but.. .the most common problem is...

Permissions.

The two main things are: that IIRF.ini can be read, and that the IIRF log file can be written.  Check the event log.  Verify that the argument provided to the RewriteLog directive is correct. 

If you hve the first problem, IIRF will do nothing.  Not even /iirfstatus will work.  If you have the 2nd problem (can't create logfile), then IIRF will work, and will respond to /iirfstatus, but it will not create a logfile.   

A tricky problem occurs when you move the ini file from some other location to the physical directory for the vdir.

Normally the physical directory of the vdir has an ACL that means any file you create will get permissions that allows IIS to read the file. But if you move a file into the directory, it brings its existing ACL with it, and doesn't get the ACL for a new file. 

Another common problem is that the directory that will eventually contain the IIRF log file, does not allow IIS to write there, or that there's a typo in the RewriteLog directive.

For diagnosing these permissions problems, icacls.exe is invaluable.  You should have it on your server. I think it's installed on all Windows servers now.

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com






Jun 1, 2010 at 11:32 AM
I've sent you £10 - you've really earned it!
 
Thanks again
 
Lee.
 


 
On Tue, Jun 1, 2010 at 11:37 AM, Lee Wilson <lee@lwnet.co.uk> wrote:
Cheeso, I decided to use the installer (wish I had done so earlier), and it works fine now.
 
I cannot for the life of me work out what is different here.  Only think I can think of is that the DLL was somehow corrupt?
 
Anyway, very happy now!
 
Lee.
 


 
On Tue, Jun 1, 2010 at 10:38 AM, Lee Wilson <lee@lwnet.co.uk> wrote:
Additional (sorry), as soon as I switched back to IsapiRewrite4.dll, all the stangeness immedately stopped.
 
Lee.

On Tue, Jun 1, 2010 at 10:37 AM, Lee Wilson <lee@lwnet.co.uk> wrote:
FYI, I have reverted to the previous IsapiRewrite4.dll, which works, but I don't have the QSA functionality.
 
Lee.

On Tue, Jun 1, 2010 at 10:34 AM, Lee Wilson <lee@lwnet.co.uk> wrote:
Right, had another go today.
 
Pretty much the same as yesterday.  I'm certain permissions are OK, in fact I've probably given more than is necessary.  I have the DLL,, the .ini files, and the logfile all setup properly.  Here's what happens.
 
The live site (http://bandbase.co.uk) will load.  Then if you click on any link, you get a standard IIS 404.  Not an ASP.Net 404.  So it looks like the filter doesn't work on subsequest requests, or it would have sent the request through the ASP.Net engine.  The initial page that was requested immediately after resetting IIS works, but nothing else.  
 
Also, if the initial page you load is not the homepage, it will load once, and then a refresh gives a 404.
 
These behaviours are only reset when I reset IIS.  Then it will happen again for the next initial page I try to load, and so on.
 
Surely this cannot be a permissions problem?  I'm getting logs, they look good, like the previous ones I sent you.
 
Also, if I browse to http://bandbase.co.uk/iirfstatus after resetting IIS, I get the status page with no errors.  I did have to put "StatusInquiry ON /IirfStatus.htm RemoteOk" in the .ini file to make the status page work.
 
None of this happens on my development PC.
 
What could be causing this?
 
 
The production server is Win2003 32 bit.
 
Thanks

Lee.
 
 
 
 


 
On Mon, May 31, 2010 at 10:52 PM, Lee Wilson <lee@lwnet.co.uk> wrote:
OK, well that's enough for today, I'll continue the battle tomorrow.
 
FYI, the rewrite seemed to work on the first URL request of a new browser session.   After that, any subsequent requests are all 404s.
 
Weird.
 
Lee.

On Mon, May 31, 2010 at 10:41 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

You're not gonna believe this, but.. .the most common problem is...

Permissions.

The two main things are: that IIRF.ini can be read, and that the IIRF log file can be written.  Check the event log.  Verify that the argument provided to the RewriteLog directive is correct. 

If you hve the first problem, IIRF will do nothing.  Not even /iirfstatus will work.  If you have the 2nd problem (can't create logfile), then IIRF will work, and will respond to /iirfstatus, but it will not create a logfile.   

A tricky problem occurs when you move the ini file from some other location to the physical directory for the vdir.

Normally the physical directory of the vdir has an ACL that means any file you create will get permissions that allows IIS to read the file. But if you move a file into the directory, it brings its existing ACL with it, and doesn't get the ACL for a new file. 

Another common problem is that the directory that will eventually contain the IIRF log file, does not allow IIS to write there, or that there's a typo in the RewriteLog directive.

For diagnosing these permissions problems, icacls.exe is invaluable.  You should have it on your server. I think it's installed on all Windows servers now.

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com







Coordinator
Jun 1, 2010 at 4:18 PM

Lee, Glad its finally working.

Thanks for the donation!

Jun 7, 2010 at 8:34 AM
Edited Jun 7, 2010 at 9:41 AM

OK, it's all good.  There is one slight issue though.  Previously, all my URLs have been accessible with or without the "default.aspx" suffix.  This has caused a problem with search engines, because they perceive this as duplicate content on my site.

Using a combination of the rule you provided and perhaps an additional rule, is there a way of doing this:

If the INCOMING URL has a suffix of "default.aspx", return a 404, otherwise, append the "default.aspx" with the QSA etc as normal?  This would mean that the "duplicate" pages will no longer be served, and I can submit the URL removal requests to the search engines.

I've tried this and it seems to work, but I would appreciate your opinion:

# IIRF.ini
#
#

RewriteLogLevel 0
RewriteLog  c:\inetpub\iirfLogs\Iirf
RewriteEngine ON
StatusInquiry ON /IirfStatus.htm RemoteOk
IterationLimit 5

# +++++++++++++++++++++++++++++++++

RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://*1$1 [R=301]


RewriteRule (.+\.)(ashx)$                   -                 [L]

RedirectRule ^/(.*)/default.aspx(.*)$  /#L$1/$2#E  [R=301]

RedirectRule ^/default.aspx(.*)$  #L$1/$2#E  [R=301]


RewriteRule ^/([^.?]*)(?

Thanks

Lee.