Support the ongoing development of Laravel.io →
Requests Session Cache
Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

Which versions of Chrome/Chromium show this issue?

Last updated 2 years ago.
0

I'm using:

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

Last updated 2 years ago.
0

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!

Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

I have same issue, any solution ?

Last updated 2 years ago.
0

Anyone?

Buler?

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

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 )

Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

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);

});
Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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

0

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,
        );
Last updated 8 years ago.
0

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...

0

Sign in to participate in this thread!

Eventy

Your banner here too?

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2024 Laravel.io - All rights reserved.