Support

I believe you mean 403, not 303, since the former is a blocked file and the latter is a redirection. Go to .htaccess Maker, Allow direct access to these files and create new entries for each of the files in your site's root you want to allow access to.

If you are getting an HTTP 303 redirection when the .htaccess asks the server to return a 403 something's not configured very well on your server. Ask your host if there are custom web server error pages, and where you can disable them.

The line you commented out is:

RewriteRule !^index.php$ - [F]

Which means: Create a rewrite rule which matches any URL whose path is not exactly index.php, as long as it is referring to a file which does exist on the server (the file existence check is the RewriteCond preceding the RewriteRule). When this is matched do not redirect or otherwise modify the URI (that is what the - means in the RewriteCond), but instead return a 403 Forbidden response – that's what the F flag does. I did not invent this very standard rewrite pattern. You can see it in all its glory in the official Apache documentation:

Using the [F] flag causes the server to return a 403 Forbidden status code to the client. While the same behavior can be accomplished using the Deny directive, this allows more flexibility in assigning a Forbidden status.

The following rule will forbid .exe files from being downloaded from your server.

RewriteRule "\.exe"   "-" [F]
This example uses the "-" syntax for the rewrite target, which means that the requested URI is not modified. There's no reason to rewrite to another URI, if you're going to forbid the request.

When using [F], an [L] is implied - that is, the response is returned immediately, and no further rules are evaluated.

Emphasis mine.

You will see there are a lot of rules like that, with different RewriteCond (Rewrite Conditions) before them. This is on purpose. This is the entire point of the custom .htaccess. The RewriteCond lines along with the matching part of the RewriteRule detect potentially malicious requests and block them by using the F rewrite flag which, as you just read in the official Apache documentation, will return an HTTP 403 Forbidden status code.

Instead, you get a redirection.

However, you have never told me a. where you are being redirected to and b. whether the file you are trying to access exists or not.

If the file does not exist, then the request is forwarded to Joomla's index.php which will try to handle it as a SEF URL. If this is the case, the redirection is absolutely expected and does not constitute an issue. That's how Joomla is supposed to work. Otherwise, SEF URLs without index.php in them would not work. This is also misleading, because depending on your template Joomla may return an error page with the wrong HTTP status code (200 OK instead of 404 Not Found or 403 Forbidden). This will NOT happen with Joomla's built-in Cassiopeia template, but it does happen a lot with the shoddy third party templates which have failed to implement correct status codes the past 17 years this has been possible and recommended. I wish I was making that up, but that's the unfortunate reality of 3rd party templates.

If the file DOES exist, however, in the site's root then what happens next depends on whether you have added an exception for it or not.

If you have added an exception there's an earlier RewriteCond block which has a RewriteRule that does not transform the URL and only has the L flag, meaning that Apache will serve the file just fine (HTTP 200 OK status).

If you have NOT added an exception then this block of code at the arrow position in your screenshot kicks in and returns an HTTP 403 Forbidden status. There is no redirection.

In this last case and this last case only if you get a redirection, something's wrong with the server, and the most likely problem is a custom error page.

You told me that the file does exist on your server, you have not added an exception to explicitly allow it, and you get an HTTP 303 instead of an HTTP 403. If you are ABSOLUTELY CERTAIN that all of the conditions you gave me are true, you have a server error. If you were wrong about whether the file exists then the only problem is that you gave me misleading information and I misdiagnosed your issue based on the information you gave me, not what is actually happening.

You're welcome!

If you want to make sense of what I wrote, read it once as I wrote it and once in reverse order (I am not joking!).

To understand what you are seeing, you will need to check a. if the file really exists on your server where you expect it to be and b. if you have added an exception for it (and regenerated the .htaccess, of course). The state of these two unknowns will help you understand the meaning of the HTTP status code you are getting.