New redirects returning 403 until app pool recycle

[RJS Profile]

Hello,
We're having an issue with Helicon ape on many IIS 7 and IIS 8 servers.

If a URL is requested before a redirect is created through Helicon a 404 is returned as expected. www.example.com/newredirect/
If a redirect rule is created for that same URL www.example.com/newredirect/ IIS will return a 403.14 - forbidden response.
The URL will continue to throw a 403 error code to any clients who accesses the URL until the App Pool recycles.

I'm not sure what is causing this behavior, if the URL is not accessed before creating the redirect rule IIS will follow the redirect without any errors.

We use Helicon to allow our clients the ability to create and modify redirects and this problem is cause issues.

Is this a known issue and is there a fix?

Thank you

[Yaroslav]

Hello.

There may be several possible reasons for this behavior. First is that you maybe using some sort of caching extension on that server or a caching middleware between that server and client. The second possibility is a client-side cache, which is unlikely to be a problem with 404 responses as they tend not to be cached on client anyway, however, you may want to double-check it by hitting Ctrl+F5 in your browser window.
And another possibility that is the folder with website lack "List folder content" NTFS permission for the user running IIS Application pool for this website. List folder content permission is required for Helicon Ape to check for .htaccess file modifications and reload the file. Another possibility is sometimes .htaccess change notification does not work is the website is configured to run from a network drive. In this case, you may need to add the following line to httpd.conf file (global Ape config):

Options -FileChangesEventedMode

This will disable default "fast" Ape mode for watching .htaccess modifications using NTFS API and switch to slower but more reliable polling mode which works with network drives.

[RJS Profile]

Thanks for the reply.

We are seeing this behavior with all of our servers. I've tested this on a fresh server with no complications or addition caching as well. It is easy to reproduce.


1. Browse to a url path that does not exist yet http://www.example.com/newredirect/ -> 404 response
2. a) Create redirect http://www.example.com/newredirect/
b) Create the newredirect folder at the root of the site
c) Copy a working .htaccess file to the folder, or create .haccess file through the IIS manager snap in, or create a fresh .htaccess file manually
3. Browse to the new redirect http://www.example.com/newredirect/ -> 403.14 response
4. Recycle app pool
5. Browse to the new redirect http://www.example.com/newredirect/ -> 301 response and a working redirect


Whatever is happening it is server side, any client connecting to the server will receive a 403.14 until the app pool is recycled.
I've directly given the App Pool full control of the directories in the test environments and whether the app pool has full permissions or minimal the server responds with a 403.14 until an app pool recycle.

What I think is happening is that IIS is not recognizing the .htaccess file until the app pool is recycled.
IIS returns the same 403.14 response to an empty folder.

To be clear this is only occurring when the URL is browsed to before the folder and .htaccess file are present.

Are you able to reproduce this?

Thanks

[Yaroslav]

Please clarify step 2.a - "Create redirect" - what you mean here?
Additionally, would it be an option for your client to add redirect rules into the top level .htaccess file, instead of creating new .htaccess in each folder he needs a redirect? Anyway, I'd like to see an .htaccess example, both global and directory level.

[RJS Profile]

To clarify creating a redirect for our use case involves the creation of a new directory in the root of the website and the creation of an .htaccess file in that directory.

Helicon is integrated into our CMS for clients to add redirects to their websites.

When a client uses the interface to create a redirect the CMS creates a folder in the root of the website and then creates the .htaccess file with the appropriate rewrite rule.

Global redirect rules are written to the web.config by our staff. Helicon ape is used to allow a client's team to create and delete redirects at will, root level redirects would allow the possibility of clients causing downtime through their updates. We use this system for hundreds of websites.

Example .htaccess file in /newredirect directory

RewriteEngine On
RewriteRule .* http://google.com [R=301,NE,L]

We're looking for a solutions to this, and to find out why the .htaccess file isn't recognized in this situation until the app pool is refreshed.

Thanks

[Yaroslav]

My idea was that Ape may not detect new .htaccess file after you have made a request to non-existent folder, however, I have just tested this scenario and can confirm that latest build of Ape I'm currently testing (it is 256 now) successfully detect new .htaccess file even after request being made to the non-existent folder. Another option for not detecting changes correctly is when your website folders are located on a network drive - in this situation Windows file changes API works unreliably. I may suggest you add the following line to your web.config file:

Options -FileChangesEventedMode

This will turn off Ape usage of NTFS API for file changes and fall back to use polling method for detecting .htaccess file modifications. This will provide more reliable modification detection for some situation at the expense of higher load to file system (files being accessed more often).

[RJS Profile]

I did some more testing with Helicon ape version 3.1.0.116, 3.1.0.124 and 3.1.0.256. This behavior doesn't seem to be present in Windows Server 2008 IIS 7, All 3 version of Helicon ape worked and detected the .htacces files.

When I tested the same versions of Helicon ape with Windows Server 2012 IIS 8 all 3 versions were unable to detect the .htaccess file.

I tried to move the Helicon ape module to the top of the module list in IIS but that didn't help, when I do the same test with other file extension types there is no caching issues.
It seems extension types supported by native IIS modules (.html, .css, .js) are able to load correctly with the same tests.

I'm not sure what is different about the Helicon ape module that would result in this behavior.

None of our website content is located on network drives.

Do you have any more suggestions that may help?

Thank you

[Yaroslav]

Hello.

As I said earlier, please try to put the following line into Ape's httpd.conf file:

Code: Select all

Options -FileChangesEventedMode

This may be a permission issue with your particular Win 2012 installation settings preventing .NET modules from detecting file changes.

[taxiservices Profile]

Thank you so much for giving this site it contain lots of information that the current new generation is facing,Helicon ape is a good and it is used by all of them and it is all mostly so good.