Did you manage to get to the bottom of this at all?

Hi, I am seeing the same issue. Was anyone able to resolve this?

Same issue here. I have no clue why this is happening but i narrowed it down to a @foreach loop... any clues???

Same here. Anybody got a solution for this? Only happens with Chrome and Chromium.

Which versions of Chrome/Chromium show this issue?

I'm using:

Google Chrome Version 35.0.1916.114 Chromium Version 34.0.1847.116 Ubuntu 14.04 aura (260972)

I'm having the same problem with a Laravel project, version 4.2:

localhost

• everything works fine
• Ubuntu 14
• Apache 2.4
• PHP 5.5

server

• net::ERR_INCOMPLETE_CHUNKED_ENCODING (only Chromium based servers)
• Debian 7
• Apache 2.2
• PHP 5.4

Would be very glad if anybody knows how to solve this!

I could solve my problem by updating the PHP version of my server from 5.4 to 5.5.

I have same issue, any solution ?

Anyone?

Buler?

For future reference and anyone else I have a 'fix':

In app/start/global.php at the end of the file I added this bit of code http://laravel.io/bin/eyyDj

This will most likely need modification.

Any luck on resolving this issue? I tried @strickdj's answer but didn't work for me.

In my case an upgrade is not an option. I have little control over the production server. :-(

I used @strickdj's answer but found that it didn't play nicely with redirects (caused errors).

I changed getOriginalContent to just getContent (see this article about the 'after' filter: http://www.stillat.com/post/laravel-4-be-careful-with-your-after-filters).

Here's the modified code: http://laravel.io/bin/ELKjE

Yea I found that getContent returns the correct value if you end up modifying the content in a view composer.

I also wrapped it in a if statement:

if( $response instanceof Illuminate\Http\Response )

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.

If you don't want to mess with those flags, you can try to use the IPv6 version of the URL, ie instead of say http://localhost:8888 you can try http://[::1]:8888.

Hope it helps

Is there a fix for this? I'm getting this with Chrome on a production site. Headers already have no-cache set. Unfortunately the laravel.io pastebin seems to have deleted both of the above postings.

I have the same problem as RobvH. Any help is appreciated.

For me this wasn't with some local test server, the problem existed only on my production release! Not even the development staging vhost on the same server. Restarting Apache solved the problem, but I worry because nobody here seems to know what causes this -- it seems that each situation/solution is different -- and it wasn't happening at first, but only after a couple days after going to production.

Relevant lines from Chromium:

int HttpStreamParser::DoReadBodyComplete(int result) {
  // When the connection is closed, there are numerous ways to interpret it.
  //
  //  - If a Content-Length header is present and the body contains exactly that
  //    number of bytes at connection close, the response is successful.
  //
  //  - If a Content-Length header is present and the body contains fewer bytes
  //    than promised by the header at connection close, it may indicate that
  //    the connection was closed prematurely, or it may indicate that the
  //    server sent an invalid Content-Length header. Unfortunately, the invalid
  //    Content-Length header case does occur in practice and other browsers are
  //    tolerant of it. We choose to treat it as an error for now, but the
  //    download system treats it as a non-error, and URLRequestHttpJob also
  //    treats it as OK if the Content-Length is the post-decoded body content
  //    length.
  //
  //  - If chunked encoding is used and the terminating chunk has been processed
  //    when the connection is closed, the response is successful.
  //
  //  - If chunked encoding is used and the terminating chunk has not been
  //    processed when the connection is closed, it may indicate that the
  //    connection was closed prematurely or it may indicate that the server
  //    sent an invalid chunked encoding. We choose to treat it as
  //    an invalid chunked encoding.
  //
  //  - If a Content-Length is not present and chunked encoding is not used,
  //    connection close is the only way to signal that the response is
  //    complete. Unfortunately, this also means that there is no way to detect
  //    early close of a connection. No error is returned.
  if (result == 0 && !IsResponseBodyComplete() && CanFindEndOfResponse()) {
    if (chunked_decoder_.get())
      result = ERR_INCOMPLETE_CHUNKED_ENCODING;
    else
      result = ERR_CONTENT_LENGTH_MISMATCH;
  }

    // TODO(mef): Investigate this. The fact is that Chrome does not do this,
    // and this library is not just being used for downloads.

    // Comment from src/content/browser/download/download_resource_handler.cc:
    // ERR_CONTENT_LENGTH_MISMATCH and ERR_INCOMPLETE_CHUNKED_ENCODING are
    // allowed since a number of servers in the wild close the connection too
    // early by mistake. Other browsers - IE9, Firefox 11.0, and Safari 5.1.4 -
    // treat downloads as complete in both cases, so we follow their lead.
    case net::ERR_CONTENT_LENGTH_MISMATCH:
    case net::ERR_INCOMPLETE_CHUNKED_ENCODING:
      return REQUEST_ERROR_SUCCESS;

Looks like it's either the invalid content-length or the server is just closing the connection before saying goodbye. So i'd look for anything that might cause symfony's response class to mis-calculate the content length or bail out early.

Further, the cause of Chrome's unique behavior seems to be right there -- it's not returning REQUEST_ERROR_SUCCESS on ERR_INCOMPLETE_CHUNKED_ENCODING the way the Chromium source is written. Google may have customized that in Chrome.

Rob

So since Laravel's pastebin seems to be no longer working properly, here's the code I posted a while back, hope it helps!

/*
|--------------------------------------------------------------------------
| Fix for Chrome / PHP 5.4 issue
| http://laravel.io/forum/02-08-2014-another-problem-only-with-chrome
|--------------------------------------------------------------------------
*/

App::after(function($request, $response)
{

	$content = $response->getContent();

	$contentLength = strlen($content);

	$response->header('Content-Length', $contentLength);

});

I've been having the same problem when using Symfony2 directly (not Laravel). I discovered my apache error_log contained lines like

[Wed Nov 05 14:39:58.615106 2014] [core:notice] [pid 609] AH00052: child pid 28817 exit signal Segmentation fault (11)

corresponding to the responses that were lacking an empty terminating chunk. Unfortunately, after I enabled core dumping and restarted apache I could no longer get the problem to occur.

Note that you can't see the chunks in browser developer tools, I had to use Wireshark to discover that the responses were missing the terminating chunk.

Thank you very much, mfregoe! You're solution worked for me.

I use streaming instead of getting content as this consumes less memory:

$stream = Storage::readStream($filename);

....
headers
....

return Response::stream(function() use ($stream, $imageMeta) {
                    fpassthru($stream);
                }, $responseCode, $headers);

And also had this problem, but in Linux only. I removed 'Content-Length' parameter and everything works OK.

$headers = array(
            'Content-Description'       => 'File Transfer',
            'Content-Type'              => $imageMeta->image_mime_type,
            'Content-Transfer-Encoding' => 'binary',
            //'Content-Length'            => File::size(storage_path()."/app/".$filename),
            'Pragma'                    => 'public',
            'Expires'                   => Carbon::createFromTimestamp(time()+3600)->toRfc2822String(),
            'Last-Modified'             => $imageMeta->updated_at->toRfc2822String(),
            'Etag'                      => $imageMeta->image_etag,
        );

We experienced this exact issue (error chunked encoding), but ours turned out to be an errant new line charachter that was creeping in some views - we fixed by removing the new line before the <?php tags at the start of one of our models.

Weird...