When I use a .htaccess that contains just this line:
FallbackResource index.php
I get this error on Chrome only:
net::ERR_INCOMPLETE_CHUNKED_ENCODING
The error appears only when access the root directory where the .htaccess is located.
IE, if .htacess is in www.mysite.org/admin then the error only appears when I type that exact URL in the nav bar.
If I go to www.mysite.org/admin/index.php or www.mysite.org/admin/some-user-friendly-url there is no error.
The error is really annoying as it delays the page load by several seconds and makes the page fail to execute some JavaScript that should happen on page load.
Like many others with this error, it only happens in Chrome. Solutions from other posts were of no help in my particular case.
Add DirectoryIndex directive to .htaccess file before FallbackResource. This fixed the problem for me.
DirectoryIndex index.php
Related
We're having a problem with our PHP site: http://midlandssmilecentres.co.uk/
The problem is as follows, if you were to access, for example http://midlandssmilecentres.co.uk/feedback.php, and then put a trailing slash, it returns the index page of the root directory. From there, you can actually put any page, i.e. http://midlandssmilecentres.co.uk/feedback.php/feedback.php, and it will return that page. We need this behaviour to stop, or a feasible work around to stop these pages being accessible.
This is causing us lots of problems with duplicate content and pages that haven't been mobilised, due to the page trying to fetch the CSS from the wrong directory. We've tried removing all of the .htaccess files on the server, however this has not fixed the issue. I've done plenty of research on files with trailing slashes and how a file can be interpreted as a directory, but couldn't find anything that could help me with this.
With .htaccess, you can redirect all .php/... pages:
RewriteEngine on
RewriteRule ^(.+?\.php)/ $1 [NC,L,R=301]
You also can change the apache configuration with:
AcceptPathInfo Off
But in this case a 404 error will be returned
https://httpd.apache.org/docs/2.2/mod/core.html#acceptpathinfo
I think you need to set a 404 REDIRECT, so instead of returning that page, it redirects to a 404 page.
I am using FallbackResource in the .htaccess file:
FallbackResource page.php
This is the only line I have in this file. When I type
www.test.com/test/no-page
I get redirected to page.php indeed. So this work (where no-page in this example is a page that of course doesn't exist). And to double check, if I removed FallbackResource from the .htaccess file, then this case doesn't work (I get an Error 500).
Now when I do:
www.test.com/test/no-page/no-page-2
I get an Error 500?
Is there anything else I need to do, or check? What I need is to have any pages not found being redirected to page.php whatever the URL is.
EDIT
Also in this question URL rewriting with PHP, someone suggests that the syntax should be:
FallbackResource /page.php
Which is also what they say in the Apache documentation: http://httpd.apache.org/docs/current/mod/mod_dir.html#fallbackresource
In my case, it only works without the /. Could someone shed some light on this as well?
I have a website on a lamp stack with little to no extra configuration other than FallbackResource /index.php present in my root .htaccess
When I load the root page (localhost ) in Chrome I receive
GET http://192.168.163.171/ net::ERR_INCOMPLETE_CHUNKED_ENCODING VM110:1
in the chrome console after about 10 seconds. If I attempt to follow the link at VM110:1 it takes me to the top of my inline Javascript.
More information / What I've tried
This does NOT occur on any other page but root
There are no 404's in the access log nor any other abnormal codes
There are no errors appearing in the apache error log.
The error does not occur in the latest version of IE or Firefox.
It caused a problem in both my local environment and hosted. The latter has absolutely no config changes and I expect to be a near default install.
When I remove the FallbackResource directive my page loads fine without the error
In index.php the root is treated no different than any other page.
This would all be a non-issue because everything loads properly BUT it prevents javascript relying on a finished page load from working.
Any further ideas on what is causing the problem or new things I can try? I've considered moving to just using mod_rewrite but this is much simpler.
Finally found the answer while working on another site:
Before FallbackResource directive be sure to add a DirectoryIndex directive with the same file. Haven't had time to research why but it fixed my issue. I blame it on a Chrome bug or possibly Chrome being super picky because no other major browser has an issue.
I fixed this error by removing the following lines from my php5filter.conf file in the Apache configuration:
<FilesMatch ".+\.ph(p3?|tml)$">
SetInputFilter PHP
SetOutputFilter PHP
</FilesMatch>
To add to Blaine's answer (as I can't yet comment):
I believe this is an Apache configuration issue, not specific to Chrome.
I recently experienced this issue, and noted the following effects in various clients, again only with the home page:
Chrome, as stated, displayed the ERR_INCOMPLETE_CHUNKED_ENCODING error, but also didn't display the page correctly. The page continued to "load" for another 5 seconds even after all the content was visible.
A simple CURL request outputted the error curl: (18) transfer closed with outstanding read data remaining. The full HTML appeared, followed by the error after a delay.
Firefox and IE initially displayed the page incorrectly, as with Chrome, and again had the ~5 second additional loading time. However, after this period, the page suddenly reformatted itself correctly. No errors were seen in the respective developer consoles.
The solution to set the DirectoryIndex to the same location as FallbackResource resolved this for all clients.
Edit: An alternative if using mod_rewrite is to use something like RewriteRule ^$ index.php which will avoid affecting all subdirectories.
I don't know whether this is expected behaviour of Apache or a bug.
In my json response '\n' causing the issue. So after removing it, issue has been solved.
I'm working on a PHP project using Apache 2.2.22 and PHP 5.3.10 and I'm running into an issue where index and index.php are being treated as the same file.
I have an admin/index.php that redirects to admin/index to allow my mod_rewrite rules in .htaccess to take over and reroute the request into a custom framework. The problem is, when the browser goes to admin/index it goes into an infinite redirect loop because the request is being sent to admin/index.php which redirects to admin/index
I've tried removing the htaccess file to see if there was a problem with my mod_rewrite rules that was causing it and it didn't change anything. It just redirects to admin/index endlessly.
I've never heard of this behavior before, skimming over some Google results and skimming through the apache configuration files didn't show anything really obvious. Has anyone seen this before and know how to fix it?
EDIT:
Below is the code being used by the index.php to redirect to index.
<?php
header("Location: index");
die();
This may be due to MultiViews being enabled:
The effect of MultiViews is as follows: if the server receives a
request for /some/dir/foo, if /some/dir has MultiViews enabled, and
/some/dir/foo does not exist, then the server reads the directory
looking for files named foo.*, and effectively fakes up a type map
which names all those files, assigning them the same media types and
content-encodings it would have if the client had asked for one of
them by name. It then chooses the best match to the client's
requirements.
— https://httpd.apache.org/docs/2.2/content-negotiation.html#multiviews
Try adding Options -MultiViews to your .htaccess
Enable rewrite Logging inside Apache and raise the log level. That way apache will tell you exactly, step by step, what request is rewritten how, in which order and why.
I am very new to Apache and .htaccess, and I had a simple question regarding how to handle 403 and 404 errors with Apache's ErrorDocument command.
Let's look at this code from an early CMS I wrote:
ErrorDocument 404 /admin/includes/access_deny.php?error=404
This will silently redirect the user to http://www.mysite.com/admin/includes/access_deny.php?error=404 when they get a 404 error.
Here is my problem, this error document will always be in the same place, with regards to the .htaccess file. However, if I need to move my installation, say to the directory subfolder, I will need to open the .htaccess file an update the to following, for it to work correctly:
ErrorDocument 404 /subfolder/admin/includes/access_deny.php?error=404
Is there a way I can have .htaccess redirect to this page admin/includes/access_deny.php?error=404 in regards to the file itself, not an absolute URL? Also, no matter where I would move the installation in the future, Apache will catch all 404 errors that are on the same level or sub-directories to this file.
Please let me know if that is not clear.
Thank you for your time.
From the manual:
URLs can begin with a slash (/) for local web-paths (relative to the DocumentRoot), or be a full URL which the client can resolve. Alternatively, a message can be provided to be displayed by the browser.
This thread may help you fix it though.