Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING Fehler

In den letzten zwei Monaten wurde auf der Chrome-Entwicklerkonsole der folgende Fehler angezeigt:

net::ERR_INCOMPLETE_CHUNKED_ENCODING

Symptome:

• Seiten werden nicht geladen.
• Abgeschnittene CSS- und JS-Dateien.
• Seiten hängen.

Serverumgebung:

• Apache 2.2.22
• PHP
• Ubuntu

Dies passiert mir auf unserem hauseigenen Apache-Server. Es passiert niemandem - dh keiner unserer Benutzer hat dieses Problem - und auch niemand in unserem Entwicklerteam.

Andere Personen greifen mit genau derselben Chrome-Version auf genau denselben Server zu. Ich habe auch versucht, alle Erweiterungen zu deaktivieren und im Inkognito-Modus zu surfen - ohne Wirkung.

Ich habe Firefox verwendet und genau das Gleiche passiert. Abgeschnittene Dateien und so weiter. Das einzige ist, dass Firefox keine Konsolenfehler auslöst. Sie müssen daher die HTTP-Anforderung über Firebug überprüfen, um das Problem zu erkennen.

Antwortheader von Apache:

Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection:close
Content-Encoding:gzip
Content-Type:text/html; charset=utf-8
Date:Mon, 27 Apr 2015 10:52:52 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Pragma:no-cache
Server:Apache/2.2.22 (Ubuntu)
Transfer-Encoding:chunked
Vary:Accept-Encoding
X-Powered-By:PHP/5.3.10-1ubuntu3.8

Während des Tests konnte ich das Problem beheben, indem ich HTTP 1.0 in meiner htaccess-Datei erzwang:

SetEnv downgrade-1.0

Dies beseitigt das Problem. Das Erzwingen von HTTP 1.0 über HTTP 1.1 ist jedoch keine geeignete Lösung.

Update : Da ich der einzige bin, bei dem dieses Problem auftritt, musste ich mehr Zeit damit verbringen, zu untersuchen, ob es sich um ein clientseitiges Problem handelt oder nicht. Wenn ich in die Chrome-Einstellungen gehe und die Option "Auf Standard wiederherstellen" verwende, verschwindet das Problem für etwa 10 bis 20 Minuten. Dann kehrt es zurück.

OK. Ich habe dies dreifach getestet und bin zu 100% sicher, dass es durch mein Antivirus (ESET NOD32 ANTIVIRUS 5) verursacht wird.

Immer wenn ich den Echtzeitschutz deaktiviere, verschwindet das Problem. Heute habe ich den Echtzeitschutz für 6-7 Stunden ausgeschaltet und das Problem ist nie aufgetreten.

Vor ein paar Augenblicken habe ich es wieder eingeschaltet, nur damit das Problem innerhalb einer Minute auftauchte.

In den letzten 24 Stunden habe ich den Echtzeitschutz ein- und ausgeschaltet, nur um sicherzugehen. Jedes Mal war das Ergebnis das gleiche.

Update: Ich bin auf einen anderen Entwickler gestoßen, der genau das gleiche Problem mit dem Echtzeitschutz seines Kaspersky-Antivirus hatte. Er hat es deaktiviert und das Problem ist verschwunden. dh Dieses Problem scheint nicht auf ESET beschränkt zu sein.

Der Fehler versucht zu sagen, dass Chrome während des Sendens der Seite abgeschnitten wurde. Ihr Problem versucht herauszufinden, warum.

Anscheinend könnte dies ein bekanntes Problem sein, das einige Versionen von Chrome betrifft. Soweit ich das beurteilen kann, ist es ein Problem, dass diese Versionen sehr empfindlich auf die Inhaltslänge des gesendeten Blocks und die ausgedrückte Größe dieses Blocks reagieren (ich könnte in diesem Fall weit entfernt sein). Kurz gesagt, ein leicht unvollständiges Header-Problem.

Andererseits kann es sein, dass der Server den Terminal-0-Längenblock nicht sendet. Welches könnte mit behoben werden ob_flush();. Es ist auch möglich, dass Chrome (oder eine Verbindung oder etwas anderes) langsam ist. Wenn die Verbindung geschlossen ist, ist die Seite noch nicht geladen. Ich habe keine Ahnung, warum das passieren könnte.

Hier ist die Antwort der paranoiden Programmierer:

<?php
    // ... your code
    flush();
    ob_flush();
    sleep(2);
    exit(0);
?>

In Ihrem Fall kann es sein, dass das Skript eine Zeitüberschreitung aufweist. Ich bin mir nicht sicher, warum es nur Sie betreffen sollte, aber es könnte an einer Reihe von Rennbedingungen liegen? Das ist eine völlige Vermutung. Sie sollten dies testen können, indem Sie die Ausführungszeit des Skripts verlängern.

<?php
    // ... your while code
    set_time_limit(30);
    // ... more while code
?>

Es kann auch so einfach sein, wie Sie Ihre Chrome-Installation aktualisieren müssen (da dieses Problem Chrome-spezifisch ist).

• https://code.google.com/p/chromium/issues/detail?id=461213
• IIS & Chrome: Ressource konnte nicht geladen werden: net :: ERR_INCOMPLETE_CHUNKED_ENCODING
• https://wordpress.org/support/topic/interface-issue-err_incomplete_chunked_encoding

UPDATE: Ich konnte diesen Fehler (endlich) replizieren, als ein schwerwiegender Fehler ausgelöst wurde, während PHP (auf demselben lokalen Host) die Pufferung ausgab . Ich stelle mir vor, die Ausgabe war zu stark verstümmelt, um von großem Nutzen zu sein (Überschriften, aber wenig oder kein Inhalt).

Insbesondere hatte ich versehentlich meinen Code, der sich rekursiv selbst aufrief, bis PHP zu Recht aufgab. Daher hat der Server den Block mit der Länge 0 des Terminals nicht gesendet - das war das Problem, das ich zuvor identifiziert habe.

Ich hatte dieses Problem. Ich habe es aufgespürt, nachdem ich die meisten anderen Antworten auf diese Frage ausprobiert habe. Dies wurde dadurch verursacht, dass der Eigentümer und die Berechtigungen des Verzeichnisses /var/lib/nginxund insbesondere des /var/lib/nginx/tmpVerzeichnisses falsch waren.

Das tmp-Verzeichnis wird von fast-cgi verwendet, um Antworten beim Generieren zwischenzuspeichern, jedoch nur, wenn sie über einer bestimmten Größe liegen. Das Problem tritt also nur sporadisch auf und tritt nur auf, wenn die generierte Antwort groß ist.

Überprüfen Sie nginx <host_name>.error_log, ob Sie Berechtigungsprobleme haben.

/var/lib/nginxStellen Sie zum Beheben sicher, dass der Eigentümer und die Gruppe aller Unterverzeichnisse Nginx sind.

Das Folgende sollte es für jeden Client beheben.

//Gather output (if it is not already in a variable, use ob_start() and ob_get_clean() )    

// Before sending output:
header('Content-length: ' . strlen($output));

Aber in meinem Fall war Folgendes eine bessere Option und hat es auch behoben:

.htaccess:

php_value opcache.enable 0

OMG, ich habe das gleiche Problem vor 5 Minuten gelöst. Ich habe mehrere Stunden damit verbracht, eine Lösung zu finden. Auf den ersten Blick löste das Deaktivieren von Antivirus das Problem unter Windows. Aber dann bemerkte ich ein Problem auf einem anderen Linux-PC ohne Antivirus. Keine Fehler in Nginx-Protokollen. Ich habe uwsgietwas über "Broken Pipe" gezeigt, aber nicht bei allen Anfragen. Weißt du was? Auf dem Gerät war kein Speicherplatz mehr vorhanden, den ich beim Neustart des Servers im Datenbankprotokoll gefunden und dfgenehmigt habe. Die einzige Erklärung dafür, warum Antivirus gelöst wurde, ist, dass es das Zwischenspeichern von Browsern verhindert (es sollte jede Anforderung überprüfen), aber Browser mit einem seltsamen Verhalten können schlechte Antworten einfach ignorieren und zwischengespeicherte Antworten anzeigen.

In meinem Fall hatte ich, /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied)was wahrscheinlich den Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING Fehler verursachte.

Ich musste es entfernen /usr/local/var/run/nginx/und von Nginx erneut erstellen lassen.

$ sudo rm -rf /usr/local/var/run/nginx/
$ sudo nginx -s stop
$ sudo mkdir /usr/local/var/run/nginx/
$ sudo chown nobody:nobody /usr/local/var/run/nginx/
$ sudo nginx

Es ist bekannt, Chrome-Problem. Laut Chrome- und Chromium-Bug-Trackern gibt es dafür keine universelle Lösung. Dieses Problem hängt nicht mit dem Servertyp und der Version zusammen, sondern ist in Chrome richtig.

Das Setzen des Content-EncodingHeaders, um identitydieses Problem für mich zu lösen.

von developer.mozilla.org

Identität | Zeigt die Identitätsfunktion an (dh keine Komprimierung oder Änderung).

Daher kann ich vorschlagen, dass Chrome in einigen Fällen die gzip-Komprimierung nicht korrekt ausführen kann.

Ich starrte nur auf ein ähnliches Problem. Und bemerkte, dass es nur passierte, wenn die Seite UTF-8-Zeichen mit einem Ordnungswert größer als 255 (dh Multibyte) enthielt.

Das Problem war schließlich, wie der Content-Length-Header berechnet wurde. Das zugrunde liegende Backend berechnete eher die Zeichenlänge als die Bytelänge. Durch Deaktivieren von Headern mit Inhaltslänge wurde das Problem vorübergehend behoben, bis ich das Back-End-Vorlagensystem reparieren konnte.

Die einfachste Lösung besteht darin, das proxy_read_timeout für Ihren festgelegten Proxy-Speicherort in Ihrer nginx.conf auf einen höheren Wert (z. B. 120s) zu erhöhen.

location / {
....
proxy_read_timeout 120s
....
}

Ich habe diese Lösung hier gefunden https://rijulaggarwal.wordpress.com/2018/01/10/atmosphere-long-polling-on-nginx-chunked-encoding-error/

Als ich auf diesen Fehler stieß (während ich einen AJAX-Aufruf von Javascript aus machte); Der Grund war, dass die Antwort des Controllers falsch war. Es wurde ein JSON zurückgegeben, der kein gültiges Format hatte.

Hier war das Problem mein Avast AV. Sobald ich es deaktiviert hatte, war das Problem weg.

Aber ich würde wirklich gerne die Ursache dieses Verhaltens verstehen.

Ich wollte nur meine Erfahrungen mit Ihnen teilen, wenn jemand das gleiche Problem mit MOODLE hat .

Unsere Moodle-Plattform war plötzlich sehr langsam, das Laden des Dashboards dauerte ungefähr 2-3 Mal länger (bis zu 6 Sekunden) als üblich und von Zeit zu Zeit wurden einige Seiten überhaupt nicht geladen (kein 404-Fehler, sondern eine leere Seite) ). In der Developer Tools Console war der folgende Fehler sichtbar:net::ERR_INCOMPLETE_CHUNKED_ENCODING.

Bei der Suche nach diesem Fehler scheint Chrome das Problem zu sein, aber wir hatten das Problem mit verschiedenen Browsern. Nach stundenlangen Recherchen und Vergleichen der Datenbanken aus den Tagen, bevor ich das Problem endlich gefunden hatte, schaltete jemand die Ereignisüberwachung ein. Im Protokoll "Konfigurationsänderungen" war diese Änderung jedoch nicht sichtbar! Durch Deaktivieren der Ereignisüberwachung wurde das Problem endgültig gelöst. Es wurden keine Regeln für die Ereignisüberwachung definiert.

Wir führen Moodle 3.1.2+ mit MariaDB und PHP 5.4 aus.

Dies geschah auf zwei verschiedenen Client-Servern, die mehrere Jahre voneinander entfernt waren, und verwendete denselben Code, der für diese Zeit ohne Probleme auf Hunderten anderer Server bereitgestellt wurde.

Bei diesen Clients geschah dies hauptsächlich bei PHP-Skripten mit HTML-Streaming, dh bei "Connection: close" -Seiten, auf denen die Ausgabe an den Browser gesendet wurde, als die Ausgabe verfügbar wurde.

Es stellte sich heraus, dass die Verbindung zwischen dem PHP-Prozess und dem Webserver vorzeitig unterbrochen wurde, bevor das Skript abgeschlossen war und lange vor einer Zeitüberschreitung.

Das Problem war opcache.fast_shutdown = 1 in der Hauptdatei php.ini. Diese Anweisung ist standardmäßig deaktiviert, aber es scheint, dass einige Serveradministratoren glauben, dass hier eine Leistungssteigerung zu verzeichnen ist. Bei all meinen Tests habe ich bei dieser Einstellung nie einen positiven Unterschied festgestellt. Nach meiner Erfahrung hat dies dazu geführt, dass einige Skripte tatsächlich langsamer ausgeführt werden, und es gibt eine schreckliche Erfolgsgeschichte, dass manchmal das Herunterfahren eingegeben wurde, während das Skript noch ausgeführt wird, oder sogar am Ende der Ausführung, während der Webserver noch aus dem Puffer liest. Es gibt einen alten Fehlerbericht aus dem Jahr 2013, der ab Februar 2017 nicht behoben wurde und möglicherweise in Zusammenhang steht: https://github.com/zendtech/ZendOptimizerPlus/issues/146

Ich habe gesehen, dass die folgenden Fehler aufgrund dieser ERR_INCOMPLETE_CHUNKED_ENCODING ERR_SPDY_PROTOCOL_ERROR auftreten. Manchmal werden korrelative Segfaults protokolliert. manchmal nicht.

Wenn eines davon auftritt, überprüfen Sie Ihre phpinfo und stellen Sie sicher, dass opcache.fast_shutdown deaktiviert ist.

Es tut mir leid zu sagen, ich habe keine genaue Antwort für Sie. Aber ich bin auch auf dieses Problem gestoßen und habe zumindest in meinem Fall einen Weg gefunden, es zu umgehen. Vielleicht bietet es jemandem, der mehr über PHP unter der Haube weiß, einige Hinweise.

Das Szenario ist, ich habe ein Array an eine Funktion übergeben. Der Inhalt dieses Arrays wird verwendet, um eine HTML-Zeichenfolge zu erstellen, die an den Browser zurückgesendet wird, indem alles in eine globale Variable eingefügt wird, die später gedruckt wird. (Diese Funktion gibt eigentlich nichts zurück. Schlampig, ich weiß, aber das ist nebensächlich.) In diesem Array befinden sich unter anderem einige Elemente, die als Referenz verschachtelte assoziative Arrays enthalten, die außerhalb dieser Funktion definiert wurden . Beim Eliminierungsprozess stellte ich fest, dass die Manipulation eines Elements innerhalb dieses Arrays innerhalb dieser Funktion, auf das verwiesen wird oder nicht, einschließlich des Versuchs, diese referenzierten Elemente zu deaktivieren, dazu führt, dass Chrome einen net :: ERR_INCOMPLETE_CHUNKED_ENCODING-Fehler auslöst und keinen Inhalt anzeigt.

Erst durch das Umrüsten des Skripts, um überhaupt keine Verweise auf die Array-Elemente anzuwenden, funktionierten die Dinge wieder normal. Ich vermute, dass dies tatsächlich ein PHP-Fehler ist, der etwas mit dem Vorhandensein der referenzierten Elemente zu tun hat, die die inhaltslangen Header abwerfen, aber ich weiß wirklich nicht genug darüber, um es sicher zu sagen.

Ich hatte dieses Problem mit einer Website in Chrome und Firefox. Wenn ich das Avast Web Shield ausschaltete, ging es weg. Ich habe es anscheinend geschafft, es mit dem laufenden Web Shield zum Laufen zu bringen, indem ich meiner htaccess-Datei einen Teil des html5-Boilerplates htaccess hinzugefügt habe:

# ------------------------------------------------------------------------------
# | Expires headers (for better cache control)                                 |
# ------------------------------------------------------------------------------

# The following expires headers are set pretty far in the future. If you don't
# control versioning with filename-based cache busting, consider lowering the
# cache time for resources like CSS and JS to something like 1 week.

<IfModule mod_expires.c>

    ExpiresActive on
    ExpiresDefault                                      "access plus 1 month"

  # CSS
    ExpiresByType text/css                              "access plus 1 week"

  # Data interchange
    ExpiresByType application/json                      "access plus 0 seconds"
    ExpiresByType application/xml                       "access plus 0 seconds"
    ExpiresByType text/xml                              "access plus 0 seconds"

  # Favicon (cannot be renamed!)
    ExpiresByType image/x-icon                          "access plus 1 week"

  # HTML components (HTCs)
    ExpiresByType text/x-component                      "access plus 1 month"

  # HTML
    ExpiresByType text/html                             "access plus 0 seconds"

  # JavaScript
    ExpiresByType application/javascript                "access plus 1 week"

  # Manifest files
    ExpiresByType application/x-web-app-manifest+json   "access plus 0 seconds"
    ExpiresByType text/cache-manifest                   "access plus 0 seconds"

  # Media
    ExpiresByType audio/ogg                             "access plus 1 month"
    ExpiresByType image/gif                             "access plus 1 month"
    ExpiresByType image/jpeg                            "access plus 1 month"
    ExpiresByType image/png                             "access plus 1 month"
    ExpiresByType video/mp4                             "access plus 1 month"
    ExpiresByType video/ogg                             "access plus 1 month"
    ExpiresByType video/webm                            "access plus 1 month"

  # Web feeds
    ExpiresByType application/atom+xml                  "access plus 1 hour"
    ExpiresByType application/rss+xml                   "access plus 1 hour"

  # Web fonts
    ExpiresByType application/font-woff                 "access plus 1 month"
    ExpiresByType application/vnd.ms-fontobject         "access plus 1 month"
    ExpiresByType application/x-font-ttf                "access plus 1 month"
    ExpiresByType font/opentype                         "access plus 1 month"
    ExpiresByType image/svg+xml                         "access plus 1 month"

</IfModule>

# ------------------------------------------------------------------------------
# | Compression                                                                |
# ------------------------------------------------------------------------------

<IfModule mod_deflate.c>

    # Force compression for mangled headers.
    # http://developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping
    <IfModule mod_setenvif.c>
        <IfModule mod_headers.c>
            SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
            RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
        </IfModule>
    </IfModule>

    # Compress all output labeled with one of the following MIME-types
    # (for Apache versions below 2.3.7, you don't need to enable `mod_filter`
    #  and can remove the `<IfModule mod_filter.c>` and `</IfModule>` lines
    #  as `AddOutputFilterByType` is still in the core directives).
    <IfModule mod_filter.c>
        AddOutputFilterByType DEFLATE application/atom+xml \
                                      application/javascript \
                                      application/json \
                                      application/rss+xml \
                                      application/vnd.ms-fontobject \
                                      application/x-font-ttf \
                                      application/x-web-app-manifest+json \
                                      application/xhtml+xml \
                                      application/xml \
                                      font/opentype \
                                      image/svg+xml \
                                      image/x-icon \
                                      text/css \
                                      text/html \
                                      text/plain \
                                      text/x-component \
                                      text/xml
    </IfModule>

</IfModule>

# ------------------------------------------------------------------------------
# | Persistent connections                                                     |
# ------------------------------------------------------------------------------

# Allow multiple requests to be sent over the same TCP connection:
# http://httpd.apache.org/docs/current/en/mod/core.html#keepalive.

# Enable if you serve a lot of static content but, be aware of the
# possible disadvantages!

 <IfModule mod_headers.c>
    Header set Connection Keep-Alive
 </IfModule>

Mein Fix ist:

<?php  ob_start(); ?>
<!DOCTYPE html>
<html lang="de">
.....
....//your whole code
....
</html>
<?php
        ob_clean();
ob_end_flush();

ob_flush();

?>

Hoffe, dies wird jemandem in Zukunft helfen, und in meinem Fall ist es ein Kaspersky-Problem, aber das obige Update funktioniert großartig :)

In meinem Fall geschah dies während der JSON-Serialisierung einer Web-API-Rückgabe-Nutzlast. Ich hatte eine "zirkuläre" Referenz in meinem Entity Framework-Modell. Ich gab ein einfaches Eins-zu-Viele-Objektdiagramm zurück, aber das Kind hatte eine Referenz zurück zu das Elternteil, das anscheinend der json serializer nicht mag. Das Entfernen der Eigenschaft für das untergeordnete Element, das auf das übergeordnete Element verweist, hat den Trick ausgeführt.

Hoffe, dies hilft jemandem, der ein ähnliches Problem haben könnte.

Überprüfen Sie die Berechtigung für den Nginx-Ordner und legen Sie die Appache-Berechtigung dafür fest:

chown -R www-data:www-data /var/lib/nginx

Ich wurde net::ERR_INCOMPLETE_CHUNKED_ENCODING bei näherer Betrachtung der Serverfehlerprotokolle fand ich , dass es zu PHP Skriptausführung Timeout zurückzuführen war.

Das Hinzufügen dieser Zeile über dem PHP-Skript hat das Problem für mich gelöst:

ini_set('max_execution_time', 300); //300 seconds = 5 minutes

Ref: Schwerwiegender Fehler: Maximale Ausführungszeit von 30 Sekunden überschritten

Für mich war dies auf unzureichenden freien Speicherplatz auf der Festplatte zurückzuführen.

Dies geschah für mich aus einem ganz anderen Grund. net :: ERR_INCOMPLETE_CHUNKED_ENCODING 200 Wenn ich die Seite inspiziere und zur Registerkarte newtork gehe, sehe ich, dass die Seite vendor.js nicht geladen werden konnte. Bei der Überprüfung scheint es, dass die Größe der JS-Datei groß ist ~ 6,5 MB. Als ich merkte, dass ich die JS komprimieren musste. Ich habe überprüft, ob ich ng buildzum Erstellen einen Befehl verwendet habe. Stattdessen hat ng build --prod --aot --vendor-chunk --common-chunk --delete-output-path --buildOptimizeres bei mir funktioniert. Siehe https://github.com/angular/angular-cli/issues/9016

Gut. Vor nicht allzu langer Zeit habe ich auch diese Frage getroffen. Und schließlich bekomme ich die Lösungen, die dieses Problem wirklich angehen.

Meine Problemsymptome sind auch, dass die Seiten nicht geladen werden und die JSON-Daten zufällig abgeschnitten wurden.

Hier sind die Lösungen, die ich zusammenfassen könnte, um dieses Problem zu lösen

1.Kill the anti-virus software process
2.Close chrome's Prerendering Instant pages feature
3.Try to close all the apps in your browser
4.Try to define your Content-Length header
  <?php
     header('Content-length: ' . strlen($output));
  ?>
5.Check your nginx fastcgi buffer is right 
6.Check your nginx gzip is open

Wenn eine Schleife oder ein Element nicht vorhanden ist, tritt dieses Problem auf.

Wenn Sie die App in Chrome ausführen, ist die Seite leer und reagiert nicht mehr.

Szenario-Start:

Entwicklungsumgebung: MAC, STS 3.7.3, tc Pivotal Server 3.1, Spring MVC Web,

in $ {myObj.getfName ()}

Szenarioende:

Grund des Problems: Die Funktion getfName () ist auf myObj nicht definiert.

Hoffe es hilft dir.

Ich vermute, der Server verarbeitet die Chunked-Transfer-Codierung nicht richtig. Es muss eine Chunk-Datei mit einem Terminal-Chunk terminieren, um anzuzeigen, dass die gesamte Datei übertragen wurde. Der folgende Code funktioniert möglicherweise:

echo "\n";
flush();
ob_flush();
exit(0);

In meinem Fall war die Konfiguration für die PHP-Erweiterung mysqlnd_ms auf dem Server fehlerhaft. Komisch ist, dass es bei Anfragen mit kurzer Dauer gut funktioniert hat. Es gab eine Warnung im Serverfehlerprotokoll, daher haben wir sie schnell behoben.

Dies scheint ein häufiges Problem mit mehreren Ursachen und Lösungen zu sein, daher werde ich meine Antwort hier für alle bereitstellen, die dies benötigen.

Ich wurde net::ERR_INCOMPLETE_CHUNKED_ENCODING auf Chrome, OSX, PHP70, httpD24 Kombination, aber der gleiche Code lief gut auf dem Produktionsserver.

Ich habe anfangs die regulären Protokolle verfolgt, aber es ist nichts wirklich aufgetaucht. Eine kurze ls -laterShow system.logwar die letzte berührte Datei in /var/logund Tailing, die mir gab

Saved crash report for httpd[99969] version 2.4.16 (805) 
to /Library/Logs/DiagnosticReports/httpd.crash

Enthalten in:

Process:               httpd [99974]
Path:                  /usr/sbin/httpd
Identifier:            httpd
Version:               2.4.16 (805)
Code Type:             X86-64 (Native)
Parent Process:        httpd [99245]
Responsible:           httpd [99974]
User ID:               70

PlugIn Path:             /usr/local/opt/php70-mongodb/mongodb.so
PlugIn Identifier:       mongodb.so

A brew uninstall php70-mongodbund a httpd -k restartspäter und alles lief reibungslos.

In meinem Fall war es eine Ausgabe von HTML. Die json-Antwort enthielt '\ n' und verursachte das Problem. Also habe ich das entfernt.

Faszinierend zu sehen, wie viele verschiedene Ursachen es für dieses Problem gibt!

Viele sagen, es ist ein Chrome-Problem, also habe ich Safari ausprobiert und hatte immer noch Probleme. Dann habe ich alle Lösungen in diesem Thread ausprobiert, einschließlich des Ausschaltens meines AVG-Echtzeitschutzes, kein Glück.

Für mich war das Problem meine .htaccessAkte. Alles, was es enthielt, war FallbackResource index.php, aber als ich es umbenannte, htaccess.txtwurde mein Problem behoben.

Hmmm, ich bin gerade auf ein ähnliches Problem gestoßen, aber mit verschiedenen Gründen dahinter ...

Ich verwende Laravel Valet für ein Vanille-PHP-Projekt mit Laravel Mix . Als ich die Site in Chrome öffnete, gab es net::ERR_INCOMPLETE_CHUNKED_ENCODINGFehler. (Wenn ich die Site auf das HTTPS-Protokoll geladen hatte, änderte sich der Fehler innet::ERR_SPDY_PROTOCOL_ERROR .)

Ich habe das php.iniund überprüftopcache war nicht aktiviert. Ich stellte fest, dass in meinem Fall das Problem mit der Versionierung der Asset-Dateien zusammenhängt - aus irgendeinem Grund schien es nicht so, als würde eine Abfragezeichenfolge in der URL der Assets gefallen (seltsamerweise nur eine?).

Ich habe mix.version()für die lokale Umgebung entfernt und die Site wird in meinem Chrome sowohl auf HTTP- als auch auf HTTPS-Protokollen einwandfrei geladen.

Im Kontext eines Controllers in Drupal 8 (Symfony Framework) hat diese Lösung für mich funktioniert:

$response = new Response($form_markup, 200, array(
  'Cache-Control' => 'no-cache',
));

$content = $response->getContent();
$contentLength = strlen($content);
$response->headers->set('Content-Length', $contentLength);

return $response;

Andernfalls hat der Antwortheader 'Transfer-Encoding' den Wert 'chunked' erhalten. Dies kann ein Problem für den Chrome-Browser sein.