net::ERR_INCOMPLETE_CHUNKED_ENCODING - .htaccess

Question

I use .htaccess to rewrite url from someurl.com/ to someurl.com/public/. First .htaccess in www root contains this:
DirectoryIndex ./public/
RewriteEngine on
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteCond %{SCRIPT_FILENAME} !-f
RewriteRule ^(.*)$ ./public/$1 [QSA]
and second one in folder /public/ contains this:
DirectoryIndex _main.php
RewriteEngine on
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteCond %{SCRIPT_FILENAME} !-f
RewriteRule ^(.*)$ ./?params=$1 [QSA]
And the problem is when I open url someurl.com/ without "public". Page is loaded correctly, but in Google Chrome console I got error: net::ERR_INCOMPLETE_CHUNKED_ENCODING. When I open url someurl.com/public/ page loads without any error.
Any ideas, please?

Answer 1

In my case, the problem was cache-related and was happening when doing a CORS request.
I post my response here cause this is the first resource I found on Google for net::ERR_INCOMPLETE_CHUNKED_ENCODING error.
Forcing the response header Cache-Control to no-cache resolved my issue:
[ using Symfony HttpFoundation component ]
<?php
$response->headers->add(array(
'Cache-Control' => 'no-cache'
));

Answer 2

I had this issue when trying to access some parts of the WP admin area, I managed to resolve it by adding the below to my functions.php file;
add_filter('wp_headers', 'wpse167128_nocache');
function wpse167128_nocache($headers){
unset($headers['Cache-Control']);
return $headers;
}

Answer 3

We had net::ERR_INCOMPLETE_CHUNKED_ENCODING problem in case of HTML, which contained too much empty lines. Some browsers had difficulties with interpretation of long files.
Once we made applied code cleaning in our templates by cleaning code from empty lines, all was perfect.

Answer 4

I was also facing same issue. Finally i got this was the permission issue on cache folder.

Answer 5

I decided changing the file : /etc/apache2/mods-enabled/cgid.conf
Adding the following code snippet:
<IfModule mod_cgid.c>
CGIDScriptTimeout 60
</IfModule>

Answer 6

This problem is really general, in my case I deactivated the WP Super Cache plugin, and didn't get the bug anymore, but this is so general that no one can really help you because of different configurations of servers/wordpress

Answer 7

In my case, the problem was the Windows anti-virus software (Kaspersky). Turning it off, the problem was gone :/

Answer 8

For me it was the Zend PHP Opcache. It had reached its memory limit and could no longer cache all scripts. This was a problem for a massive code base like Magento 2.
Increasing the memory limit solved the issue after weeks of banging head on desk.

Answer 9

It is about server side problem.
The user has running web service does not right access to web server cache folder.
Make sure nginx user can write to /var/lib/nginx (or /var/cache/nginx in some distros).
Make sure nginx user can write to the folder (find the nginx user form nginx configuration file is located usually in /etc/nginx/nginx.conf)
Give the right access (chown -R nginx:nginx /var/lib/nginx/)
Reload the service(-service nginx reload -in centos)