Basic 404 prevention iRule not working in IE (Firefox fine)

Cool rule. Is there a specific question you wanted to ask, or are you just looking for ideas on why this isn't working in IE?

 

 

Colin

What do you get in IE? Is it just blank, or do you get a 404 error?

 

 

Something that might help you debug in IE is fiddler:

 

 

http://www.fiddlertool.com/fiddler/

 

 

It'll let you see the exact request and response data send/received. I've found it quite useful in debugging weird things like this.

Wow. Sorry for the lack of detail there. I was onsite this AM digging into the issue, and didn't realize how little information I included. Now that there's a few gallons of coffee in me, here's the situation:

 

 

Again, rule works in Firefox, but not in IE. Now that I'm looking at it, HTTPwatch is showing "ERROR_INTERNET_CONNECTION_RESET" when the browswer is showing "cannot display the webpage" error comes about (not 404 like expected). I am testing this at the lab, not the customer site, so I will have to re-confirm their side tomorrow. As far as the LB_FAILED event, it is strangely working (same exact rule) in the lab - although simple tests at their site failed using IE. I'm wondering if this is a mixture of IE security and maybe even a bug in 9.3 (I've got 9.4.1 in the lab and it's catching LB_FAILED, customer has 9.3 HF1 and it is not).

 

Hope to have more details tomorrow.

So, I kind of doubt the iRule itself is having problems with IE vs FF, as it probably knows nothing about which one it is. My guess is IE might just be handling the response slightly differently.

 

 

I ran into an issue with that a little while ago. I was trying to have the iRule return a custom 404 error message if the user tried going to a path that we wanted to block. Firefox would display the contents I sent back just fine, but IE refused to and instead just showed its default 404 page (despite the fact that IE and FF were getting exactly the same data back). I never did figure out why. Your problem is probably different in that you're using a 200 response, but maybe the formatting of the response is something that IE doesn't quite like.

 

 

EDIT: I'm a moron and forgot you already posted the rule.

Random question: How come you're defining the contents using {} with subst instead of just ""? I doubt it would make any difference, but I'm kind of curious why you chose that.

No reason for the subst versus "" - this is actually a combination of a few random irules and I didn't change it. I should be back in front of the customer tomorrow, I'm interested to be able to play with the issue again. I will keep the forum posted, thanks!

 

Got it all working, and have answers for all of the behavior. So with the iRule, 404 prevention worked fine in all browsers except IE 6 at the customer site. Turns out they had some custom IE build that was somehow causing resets instead of 404s (no clue how). I had them reset IE 6 settings to default, and 404's started working. However, server down prevention messages didn't work in any browser, anywhere due to the LB::Failed usage in my iRule. I tested this using both a purposefully broken monitor, as well as simply disabling the server. I ended up switching LB::Failed to:

 

 

when HTTP_REQUEST {

 

if { [active_members http_pool] < 1 } {

 

HTTP::respond 200 content [subst $::Servers_down]

 

}

 

}

 

 

 

Thanks for all the responses