Chrome net::ERR_INCOMPLETE_CHUNKED_ENCODING-fout

De afgelopen twee maanden krijg ik de volgende foutmelding op de ontwikkelaarsconsole van Chrome:

net::ERR_INCOMPLETE_CHUNKED_ENCODING

Symptomen:

• Pagina’s laden niet.
• Afgekapte CSS- en JS-bestanden.
• Pagina’s hangen.

Serveromgeving:

• Apache 2.2.22
• PHP
• Ubuntu

Dit gebeurt bij mij op onze interne Apache-server. Het overkomt niemand anders – d.w.z. Geen van onze gebruikers ervaart dit probleem – en ook niemand anders in ons ontwikkelteam.

Andere mensen gebruiken exact dezelfde server met exact dezelfde versie van Chrome. Ik heb ook geprobeerd alle extensies uit te schakelen en te browsen in de incognitomodus – zonder resultaat.

Ik heb Firefox gebruikt en precies hetzelfde gebeurt. Afgekapte bestanden en zo. Het enige is dat Firefox geen consolefouten genereert, dus u moet het HTTP-verzoek via Firebug inspecteren om het probleem te zien.

Reactiekoppen van 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

Tijdens het testen kon ik het probleem oplossen door HTTP 1.0 in mijn htaccess-bestand te forceren:

SetEnv downgrade-1.0

Dit lost het probleem op. HTTP 1.0 forceren via HTTP 1.1 is echter geen goede oplossing.

Update: omdat ik de enige ben die dit probleem ondervindt, dacht ik dat ik meer tijd moest besteden aan het onderzoeken of het een probleem aan de kant van de klant was. Als ik naar de instellingen van Chrome ga en de optie “Standaard herstellen” gebruik, het probleem verdwijntongeveer 10-20 minuten. Dan keert het terug.

Antwoord 1, autoriteit 100%

Oké. Ik heb dit driemaal getest en ik ben 100% zekerdat het wordt veroorzaakt door mijn antivirusprogramma (ESET NOD32 ANTIVIRUS 5).

Telkens wanneer ik de realtimebeveiliging uitschakel, verdwijnt het probleem. Vandaag heb ik de realtime-beveiliging 6-7 uur uitgeschakeld en het probleem is nooit opgetreden.

Enkele ogenblikken geleden heb ik het weer aangezet, maar het probleem kwam binnen een minuut naar boven.

In de afgelopen 24 uur heb ik voor de zekerheid de realtime-beveiliging in- en uitgeschakeld. Elke keer – het resultaat is hetzelfde.

Update: ik ben een andere ontwikkelaar tegengekomen die exact hetzelfde probleem had met de realtime-beveiliging op zijn Kaspersky-antivirus. Hij schakelde het uit en het probleem was weg. d.w.z. dit probleem lijkt niet beperkt te zijn tot ESET.

Antwoord 2, autoriteit 61%

De fout probeert te zeggen dat Chrome is afgebroken terwijl de pagina werd verzonden. Je probleem probeert te achterhalen waarom.

Blijkbaar kan dit een bekend probleem zijn dat van invloed is op een aantal versies van Chrome. Voor zover ik weet, is het een kwestie van deze versies die enorm gevoelig zijn voor de inhoudslengte van het stuk dat wordt verzonden en de uitgedrukte grootte van dat stuk (ik zou daar ver naast kunnen zitten). Kortom, een ietwat onvolmaakt header-probleem.

Aan de andere kant kan het zijn dat de server de terminal van 0 lengte niet verstuurt. Wat misschien te repareren is met ob_flush();. Het is ook mogelijk dat Chrome (of verbinding of iets dergelijks) traag is. Dus wanneer de verbinding wordt gesloten, is de pagina nog niet geladen. Ik heb geen idee waarom dit zou kunnen gebeuren.

Hier is het antwoord van paranoïde programmeurs:

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

In jouw geval kan er sprake zijn van een time-out van het script. Ik weet niet echt zeker waarom het alleen jou zou moeten beïnvloeden, maar het kan te maken hebben met een aantal race-omstandigheden? Dat is een totale gok. U zou dit moeten kunnen testen door de uitvoeringstijd van het script te verlengen.

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

Het kan ook zo eenvoudig zijn als u uw Chrome-installatie moet bijwerken (aangezien dit probleem Chrome-specifiek is).

• https://code.google.com/p/chromium/ issues/detail?id=461213
• IIS & Chrome: kan resource: net::ERR_INCOMPLETE_CHUNKED_ENCODING niet laden: net::ERR_INCOMPLETE_CHUNKED_ENCODING
• https://wordpress.org/support/topic/interface-issue-err_incomplete_chunked_encoding

UPDATE:ik kon deze fout (eindelijk) repliceren toen een fatale fout werd gegenereerd terwijl PHP (op dezelfde localhost) uitvoerbuffering. Ik stel me voor dat de uitvoer te slecht was verminkt om van veel nut te zijn (kopteksten maar weinig of geen inhoud).

In het bijzonder had ik per ongeluk mijn code recursief laten oproepen totdat PHP het, terecht, opgaf. Dus de server heeft de terminal met een lengte van 0, niet verzonden – wat het probleem was dat ik eerder identificeerde.

Antwoord 3, autoriteit 41%

Ik had dit probleem. Ik heb het opgespoord na het proberen van de meeste andere antwoorden op deze vraag. Het werd veroorzaakt doordat de eigenaar en permissies van de /var/lib/nginxen meer specifiek de /var/lib/nginx/tmpdirectory onjuist waren.

De directory tmp wordt door fast-cgi gebruikt om reacties in de cache op te slaan zodra ze worden gegenereerd, maar alleen als ze groter zijn dan een bepaalde grootte. Het probleem is dus intermitterend en treedt alleen op wanneer de gegenereerde respons groot is.

Controleer de nginx <host_name>.error_logom te zien of je toestemmingsproblemen hebt.

Om dit op te lossen, moet u ervoor zorgen dat de eigenaar en groep van /var/lib/nginxen alle submappen nginx zijn.

Ik heb dit ook met tussenpozen zien gebeuren wanneer de ruimte op het opslagapparaat te laag is om het tijdelijke bestand te maken. De oplossing in dit geval is om wat ruimte op het apparaat vrij te maken.

Antwoord 4, autoriteit 22%

Het volgende zou het voor elke klant moeten oplossen.

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

Maar in mijn geval was het volgende een betere optie en loste het ook op:

.htaccess:

php_value opcache.enable 0

Antwoord 5, autoriteit 17%

OMG, ik heb hetzelfde probleem 5 minuten geleden opgelost. Ik heb enkele uren besteed aan het vinden van een oplossing. Op het eerste gezicht lost het uitschakelen van antivirus het probleem op Windows op. Maar toen merkte ik een probleem op op een andere Linux-pc zonder antivirus. Geen fouten in nginx-logboeken. Mijn uwsgitoonde iets over “Broken pipe” maar niet op alle verzoeken.
Weet je wat? Er was geen ruimte meer op het apparaat, wat ik vond toen de server opnieuw werd opgestart in het databaselogboek, en dfkeurde dit goed. De enige verklaring waarom antivirus is opgelost, is dat het browsercaching voorkomt (het zou elk verzoek moeten controleren), maar een browser met vreemd gedrag kan een slechte reactie gewoon negeren en in de cache opgeslagen reacties weergeven.

Antwoord 6, autoriteit 7%

In mijn geval had ik /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied)wat waarschijnlijk het Chrome-net tot gevolg had: :ERR_INCOMPLETE_CHUNKED_ENCODING fout.

Ik moest /usr/local/var/run/nginx/verwijderen en nginx het opnieuw laten maken.

$ 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

Antwoord 7, autoriteit 5%

Het is een bekend Chrome-probleem. Volgens Chrome en Chromium bugtrackers is hier geen universele oplossing voor. Dit probleem is niet gerelateerd aan het servertype en de versie, het zit in Chrome.

Het instellen van Content-Encodingheader op identityloste dit probleem voor mij op.

van developer.mozilla.org

identiteit | Geeft de identiteitsfunctie aan (d.w.z. geen compressie, nor
wijziging).

Dus ik kan suggereren dat Chrome in sommige gevallen gzip-compressie niet correct kan uitvoeren.

Antwoord 8, autoriteit 5%

De eenvoudigste oplossing is om de proxy_read_timeout voor uw ingestelde proxylocatie te verhogen naar een hogere waarde (laten we zeggen 120s) in uw nginx.conf.

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

Ik heb deze oplossing hier gevonden
https://rijulaggarwal .wordpress.com/2018/01/10/atmosphere-long-polling-on-nginx-chunked-encoding-error/

Antwoord 9, autoriteit 4%

Ik had net een soortgelijk probleem. En merkte op dat het alleen gebeurde wanneer de pagina UTF-8-tekens bevatte met een ordinale waarde groter dan 255 (d.w.z. multibyte).

Wat uiteindelijk het probleem was, was hoe de header Content-Length werd berekend. De onderliggende backend was het berekenen van de tekenlengte in plaats van de bytelengte. Het uitschakelen van kopteksten met de lengte van de inhoud loste het probleem tijdelijk op totdat ik het backend-sjabloonsysteem kon repareren.

Antwoord 10, autoriteit 4%

Toen ik deze fout tegenkwam (tijdens het maken van AJAX-oproep vanuit javascript); de reden was dat de reactie van de controller onjuist was; het gaf een JSON terug die geen geldig formaat had.

Antwoord 11, autoriteit 2%

Hier was het probleem mijn Avast AV.
Zodra ik het uitschakelde, was het probleem verdwenen.

Maar ik zou graag de oorzaak van dit gedrag willen begrijpen.

Antwoord 12, autoriteit 2%

Ik wilde alleen mijn ervaring met je delen als iemand hetzelfde probleem heeft met MOODLE.

Ons moodle-platform was plotseling erg traag, het laden van het dashboard duurde ongeveer 2-3 keer langer (tot 6 seconden) dan normaal en van tijd tot tijd werden sommige pagina’s helemaal niet geladen (geen 404-fout maar een blanco pagina). In de Developer Tools Console was de volgende fout zichtbaar: net::ERR_INCOMPLETE_CHUNKED_ENCODING.

Bij het zoeken naar deze fout lijkt het erop dat Chrome het probleem is, maar we hadden het probleem met verschillende browsers. Na urenlang onderzoek en het vergelijken van de databases van de dagen voordat ik het probleem eindelijk vond, zette iemand Event Monitoring aan. In het log “Config changes” was deze wijziging echter niet zichtbaar! Door Event Monitoring uit te zetten, was het probleem eindelijk opgelost – we hadden geen regels gedefinieerd voor event monitoring.

We gebruiken Moodle 3.1.2+ met MariaDB en PHP 5.4.

Antwoord 13, autoriteit 2%

Dit gebeurde op de servers van twee verschillende clients die meerdere jaren van elkaar waren gescheiden, waarbij dezelfde code werd gebruikt die voor die tijd zonder problemen op honderden andere servers werd geïmplementeerd.

Voor deze clients gebeurde het meestal op PHP-scripts met streaming HTML – dat wil zeggen “Verbinding: sluiten”-pagina’s waar de uitvoer naar de browser werd gestuurd zodra de uitvoer beschikbaar kwam.

Het bleek dat de verbinding tussen het PHP-proces en de webserver voortijdig wegviel, voordat het script voltooid was en ver voor een time-out.

Het probleem was opcache.fast_shutdown = 1 in het hoofdbestand van php.ini. Deze richtlijn is standaard uitgeschakeld, maar het lijkt erop dat sommige serverbeheerders denken dat hier een prestatieverbetering te behalen is. In al mijn tests heb ik nooit een positief verschil opgemerkt met deze instelling. In mijn ervaring heeft het ertoe geleid dat sommige scripts langzamer worden uitgevoerd, en heeft het een verschrikkelijk trackrecord van soms afsluiten terwijl het script nog wordt uitgevoerd, of zelfs aan het einde van de uitvoering terwijl de webserver nog uit de buffer leest. Er is een oud bugrapport uit 2013, onopgelost vanaf februari 2017, wat mogelijk gerelateerd is: https: //github.com/zendtech/ZendOptimizerPlus/issues/146

Ik heb hierdoor de volgende fouten zien verschijnen
ERR_INCOMPLETE_CHUNKED_ENCODING
ERR_SPDY_PROTOCOL_ERROR
Soms zijn er correlatieve segfaults gelogd; soms niet.

Als je een van beide ervaart, controleer dan je phpinfo en zorg ervoor dat opcache.fast_shutdown is uitgeschakeld.

Antwoord 14

Het spijt me te moeten zeggen, ik heb geen precies antwoord voor je. Maar ik kwam dit probleem ook tegen en vond, althans in mijn geval, een manier om het te omzeilen. Dus misschien biedt het wat aanwijzingen voor iemand anders die meer weet over Php onder de motorkap.

Het scenario is dat ik een array heb doorgegeven aan een functie. De inhoud van deze array wordt gebruikt om een ​​HTML-string te produceren die teruggestuurd moet worden naar de browser, door alles in een globale variabele te plaatsen die later wordt afgedrukt. (Deze functie retourneert eigenlijk niets. Slordig, ik weet het, maar dat is niet ter zake.) Binnen deze array bevinden zich onder andere een aantal elementen die, door verwijzing, geneste associatieve arrays dragen die buiten deze functie zijn gedefinieerd . Door eliminatieproces ontdekte ik dat manipulatie van elk element in deze array binnen deze functie, waarnaar wordt verwezen of niet, inclusief een poging om die elementen waarnaar wordt verwezen uit te schakelen, ertoe leidt dat Chrome een net::ERR_INCOMPLETE_CHUNKED_ENCODING-fout gooit en geen inhoud weergeeft. Dit ondanks het feit dat de HTML-string in de globale variabele precies is wat hij zou moeten zijn.

Alleen door het script opnieuw te bewerken om in de eerste plaats geen verwijzingen naar de array-elementen toe te passen, begonnen de dingen weer normaal te werken. Ik vermoed dat dit eigenlijk een Php-bug is die iets te maken heeft met de aanwezigheid van de elementen waarnaar wordt verwezen die de headers met de lengte van de inhoud weggooien, maar ik weet hier echt niet genoeg van om met zekerheid te zeggen.

Antwoord 15

Ik had dit probleem met een site in Chrome en Firefox. Als ik Avast Web Shield uitschakelde, verdween het. Het lijkt erop dat ik erin geslaagd ben om het te laten werken met Web Shield uitgevoerd door een deel van de html5-boilerplate htaccess toe te voegen aan mijn htaccess-bestand:

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

Antwoord 16

Mijn oplossing is:

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

Ik hoop dat dit iemand in de toekomst zal helpen, en in mijn geval is het een Kaspersky-probleem, maar de bovenstaande oplossing werkt geweldig 🙂

Antwoord 17

In mijn geval gebeurde het tijdens json-serialisatie van een web-api-retourlading – ik had een ‘circulaire’ verwijzing in mijn Entity Framework-model, ik stuurde een eenvoudige één-op-veel-objectgrafiek terug, maar het kind had een verwijzing terug naar de ouder, wat blijkbaar de json-serializer niet leuk vindt. Het verwijderen van de eigenschap van het kind dat naar de ouder verwees, deed de truc.

Ik hoop dat dit iemand helpt die een soortgelijk probleem heeft.

Antwoord 18

Controleer de nginx-maprechten en stel daarvoor appache-rechten in:

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

Antwoord 19

Ik kreeg net::ERR_INCOMPLETE_CHUNKED_ENCODING, bij nadere inspectie van de serverfoutlogboeken ontdekte ik dat dit te wijten was aan een time-out voor de uitvoering van het PHP-script.

Het toevoegen van deze regel aan het PHP-script loste het voor mij op:

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

Ref: Fatale fout: maximale uitvoeringstijd van 30 seconden overschreden

Antwoord 20

Bij mij werd het veroorzaakt door onvoldoende vrije ruimte op de harde schijf.

Antwoord 21

dit gebeurde voor mij om een ​​heel andere reden.
net::ERR_INCOMPLETE_CHUNKED_ENCODING 200
wanneer ik de pagina inspecteer en naar het tabblad newtork ga, zie ik dat de vendor.js-pagina niet kan worden geladen. Bij controle lijkt het erop dat de grootte van het js-bestand groot is ~ 6.5 mb. Toen realiseerde ik me dat ik de js moest comprimeren. Ik heb gecontroleerd of ik de opdracht ng buildgebruikte om te bouwen. In plaats daarvan, toen ik ng build --prod --aot --vendor-chunk --common-chunk --delete-output-path --buildOptimizergebruikte, werkte het voor mij.see https://github.com/angular/angular-cli/issues/9016

Antwoord 22

als u het juiste antwoord kunt krijgen in uw localhost en deze fout krijgt en als u nginxgebruikt.

1. Ga naar Server en open nginx.conf met :

   nano etc/nginx/nginx.conf

2. Voeg de volgende regel toe in het http-blok:

   proxy_buffering uit;

3. Bewaar het bestand en sluit het af

Dit heeft mijn probleem opgelost

Antwoord 23

Nou. Niet zo lang geleden kwam ik deze vraag ook tegen. En tot slot krijg ik de oplossingen die dit probleem echt aanpakken.

Mijn probleemsymptomen zijn ook dat de pagina’s niet worden geladen en dat de json-gegevens willekeurig zijn afgekapt.

Hier zijn de oplossingen die ik samenvat om dit probleem op te lossen

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

Antwoord 24

Als er een lus of item is dat niet bestaat, heb je te maken met dit probleem.

Als de app in Chrome wordt uitgevoerd, is de pagina leeg en reageert deze niet meer.

Start scenario:

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

in ${myObj.getfName()}

Einde scenario:

Reden van het probleem: de functie getfName() is niet gedefinieerd op de myObj.

Ik hoop dat het je helpt.

Antwoord 25

mijn gok is dat de server de chunked transfer-codering niet correct verwerkt. Het moet een chunked bestand terminalen met een terminal chunk om aan te geven dat het hele bestand is overgedragen. Dus de onderstaande code werkt misschien:

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

Antwoord 26

In mijn geval was het een kapotte configuratie voor de mysqlnd_ms php-extensie op de server. Het grappige is dat het prima werkte op verzoeken van korte duur. Er was een waarschuwing in het foutenlogboek van de server, dus we hebben het snel opgelost.

Antwoord 27

Dit lijkt een veelvoorkomend probleem met meerdere oorzaken en oplossingen, dus ik ga mijn antwoord hier plaatsen voor iedereen die het nodig heeft.

Ik kreeg net::ERR_INCOMPLETE_CHUNKED_ENCODINGop de combinatie Chrome, osx, php70, httpd24, maar dezelfde code werkte prima op de productieserver.

Ik heb aanvankelijk de reguliere logs gevolgd, maar er kwam niets echt uit. Een snelle ls -latertoonde aan dat system.loghet laatste aangeraakte bestand was in /var/log, en de tailing gaf me

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

Opgenomen 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

Een brew uninstall php70-mongodben een httpd -k restartlater en alles verliep soepel.

Antwoord 28

In mijn geval was het een kwestie van html. Er was ‘\n’ in de json-reactie die het probleem veroorzaakte. Dus dat heb ik verwijderd.

Antwoord 29

Boeiend om te zien hoeveel verschillende oorzaken er zijn voor dit probleem!

Velen zeggen dat het een Chrome-probleem is, dus ik probeerde Safari en had nog steeds problemen. Daarna alle oplossingen in deze thread geprobeerd, inclusief het uitschakelen van mijn AVG Realtime Protection, geen geluk.

Voor mij was het probleem mijn .htaccess-bestand. Het bevatte alleen FallbackResource index.php, maar toen ik het hernoemde naar htaccess.txt, was mijn probleem opgelost.

Antwoord 30

Hmmm ik stuitte net op een soortgelijk probleem, maar met verschillende redenen achter…

Ik gebruik Laravel Valetop een vanille PHP-project met Laravel Mix. Toen ik de site in Chrome opende, gaf deze net::ERR_INCOMPLETE_CHUNKED_ENCODINGfouten. (Als ik de site op het HTTPS-protocol had geladen, veranderde de fout in net::ERR_SPDY_PROTOCOL_ERROR.)

Ik heb gecontroleerd of de php.inien opcacheniet was ingeschakeld. Ik ontdekte dat in mijn geval het probleem te maken had met het versiebeheer van de activabestanden – om de een of andere reden leek het geen zin te hebben in een queryreeks in de URL van de activa (nou ja, vreemd genoeg, slechts één in het bijzonder?).

Ik heb mix.version()verwijderd voor de lokale omgeving en de site laadt prima in mijn Chrome op zowel HTTP- als HTTPS-protocollen.