14

I've seen lots of these reports, but none regarding the most recent laravel 5.1.1 (LTS). Have just started a new app, and I'm receiving the following error when requesting app.local/:

GET http://app.local/ net::ERR_INCOMPLETE_CHUNKED_ENCODING

It takes just over 5 seconds for it to come to this conclusion.

Now, this is essentially a fresh installation - I've only made the following changes:

  1. Use FallbackResource instead of mod_rewrite for sending the request to index.php, and
  2. Set the application path to /../name.application/bootstrap/autoload.php in index.php (moved app, config, etc to name.application directory.

I only get the above error when sending a request to the root of the domain - that is app.local/. There is an existing route for this, and it is set to return "Hello" (return response('Hello')). That response is displayed immediately, but the page continues to load for 5 seconds, and then the console throws that error.

If I request /test, the response is snappy, and I don't receive the error.

Seemingly, this is a Laravel problem, and I'm not quite sure where it comes from. It's not an .htaccess problem as reverting my changes makes no difference. Alternatively, it could be an Apache problem, but nothing points to that being the case.

For reference, I'm running Apache 2.4 with PHP 5.6 on Windows 8.1.

This issue isn't limited to Chrome like others have reported for previous versions.

Any guidance would be appreciated.

Update: Having tested on the same VirtualHost, Laravel 4.2 appears to be doing the same thing. Could this, in fact, be a server issue?

Mike Rockétt
  • 8,947
  • 4
  • 45
  • 81
  • Seems there are many wildly [different reasons](https://stackoverflow.com/questions/22608564/neterr-incomplete-chunked-encoding-in-chrome-only) people have seen this, perhaps try one of them. – Nilithus Jun 25 '15 at 17:48
  • Thanks for pointing me to that post - hadn't seen it before. – Mike Rockétt Jun 26 '15 at 04:11

3 Answers3

2

After having looked at the answers here and realising that this is a bizarre issue, I tried falling back to the normal mod_rewrite approach, and it started working as expected.

Interestingly enough, this did not happen the first time, which is why the question was posted.

As such, this is more than likely a server issue. Running the app from a production server with the setup described in my question worked perfectly.

Mike Rockétt
  • 8,947
  • 4
  • 45
  • 81
1

I don't have enough reputation to comment, which is all this warrants as opposed to a response. Generally this is related to caching, either at the server or application level. Assuming this is a completely default install (no app.php configuration), things to check:

File permissions. By default Laravel will use "file" based caching: http://laravel.com/docs/5.1/cache

Incorrect file permissions in some server configurations can cause this (see here to set correct permissions: http://laravel.com/docs/5.1/installation#basic-configuration). If permissions are correct, swap to Database caching and see if that makes a difference (You'll need to create the schema).

Apache error logs. Same situation, if Laravel is streaming some output then failing on index, may be some information here.

If it's a non-standard Laravel install, knowing what you've configured would help?

jpg
  • 81
  • 7
  • Hi jpg, thanks for your response. It seems to make no difference if I switch to database caching, and the file permissions are correct by default (especially considering the fact that I'm running on Windows). Also, nothing relevant in the logs. It just seems super weird that it does this with a fresh installation, and only on the root. Essentially, this isn't a huge issue as the app will redirect `/` to `/home` anyway, which relieves me of the problem. Nonetheless, I'd like to be able to find out what is causing it. Thanks again. – Mike Rockétt Jun 22 '15 at 04:14
-1

Please also note that the .local TLD is reserverd for Multicast DNS (Bonjour etc) https://en.wikipedia.org/wiki/.local

edit:

Name resolution issues may arise if multicast DNS software is used in conjunction with a network that implements the local top-level DNS domain.

http://laravel.io/forum/02-08-2014-another-problem-only-with-chrome?page=1#reply-15185

It looks like this comes from a chrome flag, "Built-in Asynchronous DNS". You can navigate to chrome://flags in Chrome / Chromium, set this flag to "disabled" and relaunch the browser. After this localhost will work like a charm.

Might be relevant, or might not be, but will prevent future DNS problems...

Jimbolino
  • 404
  • 3
  • 8