RewriteProxy - 404 pages not passing through

[PCLoadLetter Profile]

Hi,

We have a RewriteProxy setup to send all *.whatever files through our proxy (destination configured by a hostmap which isnt important)

RewriteProxy (/.*\.whatever.*|/.*\.whatever1.*) ${hostmap:%2}$1 [H, A]


Im noting the RewriteProxy works great for all regular 200 status requests. However, I noticed today that we have an error page that we want proxied through, and its returning a status code of 404. The proxy debug has the correct proxy URL, but a blank page is rendered to the client (with r404 status).

Does RewriteProxy not grab 404 status code pages?

If not, can we enable it so that it can?

[HeliconAndrew]

hello,

What is your IIS version?

Please, provide rewrite.log for the testing request.
Logging issues described in FAQ

Regards
Andrew

[PCLoadLetter Profile]

IIS7,

I will send you the log in PM

[PCLoadLetter Profile]

Could it be that Helicon does not process "Error pages". That is possibly it.

We have an error page setup, lets say "error.boom"

We have *.boom mapped via helicon, those rules dont seem to be processed for the error pages. Perhaps this all happens after Helicon ISAPIRewrite has done its magic?

[HeliconAndrew]

Hello,

ISAPI_Rewrite is capable of returning custom 404 pages.
I've seen your logs and they show that everything has been proxyed correctly. there's something else, not necessarily in ISAPI_Rewrite. If you can access your 404 directly from front-end it should work fine.

Regards
Andrew

[PCLoadLetter Profile]

We hit an HTML file, 404 is issued.

IIS serves the customer 404 page, error.whatever

*.whatever files all need to be proxied by Helicon in order to be rendered. In this case hitting it directly is rendering. Also if I switch the error page to "error.html" instead of "error.whatever" it renders correctly.

I don't see anything in the logs for Helicon on the "error.whatever" page. The custom 404 we have setup needs to be Proxied by Helicon. Is perhaps that not working?

I am using NotificationType=PREPROC_HEADERS if that matters.

[HeliconAndrew]

Well, the log states, that the entry in the mapfile is found... it's proxyed to the specified path.

(5) map lookup OK: map=h[txt] key=staging.yoursite.org -> val=XX.XXX.XXX.XXX:XXXX/websitecontent/yoursite.org/htdocs
(2) forcing proxy-throughput with XX.XXX.XXX.XXX:XXXX/websitecontent/yoursite.org/htdocs/404/html404.cfm

Is it the page you need? Or what is the landing page you need?
If yes, than ISAPI_Rewrite is working fine and there's nothing you can setup.

NotificationType=PREPROC_HEADERS is a magical directive that allows IIS to process requests prior to ISAPI_rewrite. There might be a small chance of it affecting your situation. We may suggest commenting out this line for the sake of experiment.

Regards
Andrew

[PCLoadLetter Profile]

That's the right file. That example was from a direct hit to the page, which is proxied correctly. The only time it is seemingly failing is if IIS returns that exact same page as a custom error page.

[PCLoadLetter Profile]

I tried turning off preproc headers with no luck. If I request the error page directly, it works great and I see that request in the Helicon logs.

If I hit an invalid page, I see that request in the Helicon logs.

However, I do not see the request for the 404 page in the Helicon logs.

I have IIS setup to "Execute a URL on this site". I believe this does work however with a file extension that IIS has a handler for, so maybe it's something with that. I'll keep digging.

[HeliconAndrew]

Please, contact us using helpdesk or email to provide with remote access to your server.
We' d be happy to help you in resolving this issue.

Regards
Andrew

[HeliconAndrew]

Would you, please, also, clarify what is "Execute a URL on this site".

Regards
Andrew

[PCLoadLetter Profile]

"Execute a URL on this site" is a method of setting up your 404 error page in IIS7.

My testing is concluding that ISAPIRewrite does NOT process 404 error pages.

I setup an error page at: /new404/404.html

I created a simple html page at: /redirected.html

I created a rule to redirect the error page to the redirected.html:

RewriteRule ^new404/404.html$ /redirected.html [NC,R=301,L]

If I hit /new404/404.html from a browser I'm redirected as I'd expect.

If I hit a fake page, which 404's I get the contents of /new404/404.html, but no redirect or anything, and the original requested page is in the Helicon logs, but not a second request for the 404 page, new404/404.html.

It would appear that Helicon ISAPIRewrite does not "get" the request for the 404 page, and therefore will not process rules based on it. This is really bad for me because I'm trying to proxy my error pages using Helicon.

See if you can replicate this please, the test is pretty quick to setup. Any help is appreciated.

[HeliconAndrew]

Let me get it right. If you turn off the "Execute URL on a site" everything works?
Can you avoid this feature ?

Regards
Andrew

[PCLoadLetter Profile]

That's just how you setup error pages in IIS, you can't turn it off.

I'm not sure we're on the same page.

Error pages being served by IIS aren't being handled by ISAPRewrite.

[HeliconAndrew]

I'm sorry, I might not have put it right.
I meant to switch to "Insert content from static file". Can you do that?

Regards
Andrew

[PCLoadLetter Profile]

That works but it is not handled by ISAPIRewrite (Im not even sure a web request is made in that case).

I need my error page proxied out via ISAPIRewrite. My error page uses a scripting language and we proxy all requests to this scripting language out to another machine.

[HeliconAndrew]

You might be right. I could be just taking too much time and the focus is getting loose on my side due to a large number of other customers.
Lets try to do it once again, as I'm getting confued with all those details along the line.

Please, provide us with the rules, logs, basic concept using email or helpdesk all in one peace(our developers will try to replicate your environment):
1. What is the initial request
2. what should happen on front-end (if, for example, it's a static page)
3. what back-end is supposed to do
4. what does it mean "*.boom mapped via helicon"?

Regards
Andrew

[PCLoadLetter Profile]

OK, I'll shoot over a request via the ticket system