Chrome net :: errore ERR_INCOMPLETE_CHUNKED_ENCODING

Negli ultimi due mesi ho ricevuto il seguente errore sulla console per sviluppatori di Chrome:

net::ERR_INCOMPLETE_CHUNKED_ENCODING

Sintomi:

• Le pagine non si stanno caricando.
• File CSS e JS troncati.
• Pagine sospese.

Ambiente server:

• Apache 2.2.22
• PHP
• Ubuntu

Questo sta accadendo a me sul nostro server Apache interno. Non sta succedendo a nessun altro - vale a dire che nessuno dei nostri utenti sta riscontrando questo problema - né nessun altro nel nostro team di sviluppo.

Altre persone accedono allo stesso identico server con la stessa identica versione di Chrome. Ho anche provato a disabilitare tutte le estensioni e la navigazione in modalità di navigazione in incognito - senza alcun risultato.

Ho usato Firefox e sta succedendo esattamente la stessa cosa. File troncati e quant'altro. L'unica cosa è che Firefox non genera errori della console, quindi è necessario ispezionare la richiesta HTTP tramite Firebug per vedere il problema.

Header di risposta da 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

Durante il test, sono stato in grado di risolvere il problema forzando HTTP 1.0 nel mio file htaccess:

SetEnv downgrade-1.0

Questo elimina il problema. Tuttavia, forzare HTTP 1.0 su HTTP 1.1 non è una soluzione adeguata.

Aggiornamento : poiché sono l'unico a riscontrare questo problema, ho pensato che avrei dovuto dedicare più tempo a indagare se si trattava o meno di un problema lato client. Se vado nelle impostazioni di Chrome e utilizzo l'opzione "Ripristina predefiniti", il problema scompare per circa 10-20 minuti. Quindi ritorna.

OK. Ho testato tre volte questo e sono sicuro al 100% che sia causato dal mio antivirus (ESET NOD32 ANTIVIRUS 5).

Ogni volta che disabilito la protezione in tempo reale, il problema scompare. Oggi ho lasciato la protezione in tempo reale disattivata per 6-7 ore e il problema non si è mai verificato.

Qualche istante fa, l'ho riacceso, solo per far emergere il problema entro un minuto.

Nel corso delle ultime 24 ore, ho attivato e disattivato di nuovo la protezione in tempo reale, per essere sicuro. Ogni volta - il risultato è stato lo stesso.

Aggiornamento: mi sono imbattuto in un altro sviluppatore che ha avuto lo stesso identico problema con la protezione in tempo reale sul suo antivirus Kaspersky. Lo disabilitò e il problema scomparve. cioè questo problema non sembra essere limitato a ESET.

L'errore sta tentando di dire che Chrome è stato interrotto durante l'invio della pagina. Il tuo problema sta cercando di capire perché.

Apparentemente, questo potrebbe essere un problema noto che interessa un paio di versioni di Chrome. Per quanto posso dire, è un problema di queste versioni che sono enormemente sensibili alla lunghezza del contenuto del blocco inviato e alla dimensione espressa di quel blocco (potrei essere molto lontano su quello). In breve, un problema di intestazioni leggermente imperfetto.

D'altra parte, è possibile che il server non invii il blocco di lunghezza 0 del terminale. Che potrebbe essere risolvibile con ob_flush();. È anche possibile che Chrome (o la connessione o qualcosa del genere) sia lento. Pertanto, quando la connessione viene chiusa, la pagina non è ancora stata caricata. Non ho idea del perché ciò possa accadere.

Ecco la risposta dei programmatori paranoici:

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

Nel tuo caso, potrebbe trattarsi del timeout dello script. Non sono davvero sicuro del motivo per cui dovrebbe interessare solo te, ma potrebbe dipendere da un sacco di condizioni di gara? Questa è una supposizione assoluta. Dovresti essere in grado di testarlo estendendo il tempo di esecuzione dello script.

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

Potrebbe anche essere semplice quanto è necessario aggiornare l'installazione di Chrome (poiché questo problema è specifico di Chrome).

• https://code.google.com/p/chromium/issues/detail?id=461213
• IIS e Chrome: impossibile caricare la risorsa: net :: ERR_INCOMPLETE_CHUNKED_ENCODING
• https://wordpress.org/support/topic/interface-issue-err_incomplete_chunked_encoding

AGGIORNAMENTO: Sono stato in grado di replicare questo errore (alla fine) quando è stato generato un errore fatale mentre PHP (sullo stesso localhost) stava eseguendo il buffering dell'output . Immagino che l'output sia stato troppo malmenato per essere di grande utilità (intestazioni ma contenuto scarso o nullo).

In particolare, ho accidentalmente avuto il mio codice che si chiamava in modo ricorsivo fino a quando PHP, giustamente, ha rinunciato. Pertanto, il server non ha inviato il blocco di lunghezza 0 del terminale, che era il problema identificato in precedenza.

Ho avuto questo problema. Ho rintracciato dopo aver provato la maggior parte delle altre risposte a questa domanda. È stato causato dal proprietario e dalle autorizzazioni della /var/lib/nginxe, più specificamente, dalla /var/lib/nginx/tmpdirectory errata.

La directory tmp viene utilizzata da fast-cgi per memorizzare nella cache le risposte man mano che vengono generate, ma solo se superano una determinata dimensione. Quindi il problema è intermittente e si verifica solo quando la risposta generata è grande.

Controlla nginx <host_name>.error_logper vedere se riscontri problemi di autorizzazione.

Per risolvere il problema, assicurati che il proprietario e il gruppo di /var/lib/nginxe tutte le directory secondarie siano nginx.

Quanto segue dovrebbe risolverlo per ogni client.

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

Ma nel mio caso, la seguente era un'opzione migliore e anche risolta:

.htaccess:

php_value opcache.enable 0

OMG, ho risolto lo stesso problema 5 minuti fa. Ho trascorso diverse ore a trovare una soluzione. A prima vista la disabilitazione dell'antivirus ha risolto il problema su Windows. Ma poi ho notato un problema su un altro PC Linux senza antivirus. Nessun errore nei registri nginx. Il mio ha uwsgimostrato qualcosa su "Broken pipe" ma non su tutte le richieste. Sai cosa? Non era rimasto spazio sul dispositivo, che ho trovato al riavvio del server nel registro del database e l'ho dfapprovato. L'unica spiegazione del motivo per cui l'antivirus è stato risolto è che impedisce la memorizzazione nella cache del browser (dovrebbe controllare ogni richiesta), ma il browser con un comportamento strano può semplicemente ignorare la cattiva risposta e mostrare le risposte memorizzate nella cache.

Nel mio caso stavo avendo /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied)che probabilmente stava causando l'errore Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING.

Ho dovuto rimuovere /usr/local/var/run/nginx/e lasciare che nginx lo creasse di nuovo.

$ 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

È noto problema di Chrome. Secondo i bug tracker di Chrome e Chromium non esiste una soluzione universale per questo. Questo problema non è correlato al tipo e alla versione del server, è proprio in Chrome.

L'impostazione Content-Encodingdell'intestazione mi ha identityrisolto questo problema.

da developer.mozilla.org

identità | Indica la funzione identità (ovvero nessuna compressione o modifica).

Quindi, posso suggerire che in alcuni casi Chrome non è in grado di eseguire correttamente la compressione gzip.

Ho appena visto un problema simile. E ho notato che stava succedendo solo quando la pagina conteneva caratteri UTF-8 con un valore ordinale maggiore di 255 (cioè multibyte).

Quello che alla fine è stato il problema è stato il modo in cui è stata calcolata l'intestazione Content-Length. Il backend sottostante stava calcolando la lunghezza dei caratteri, piuttosto che la lunghezza dei byte. La disattivazione delle intestazioni di lunghezza del contenuto ha risolto temporaneamente il problema fino a quando non sono riuscito a risolvere il sistema di modello di back-end.

La soluzione più semplice è aumentare proxy_read_timeout per la posizione proxy impostata su un valore più alto (diciamo 120s) in nginx.conf.

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

Ho trovato questa soluzione qui https://rijulaggarwal.wordpress.com/2018/01/10/atmosphere-long-polling-on-nginx-chunked-encoding-error/

Quando ho riscontrato questo errore (durante la chiamata AJAX da javascript); il motivo era che la risposta del controller era errata; stava restituendo un JSON che non era di formato valido.

Qui il problema era il mio Avast AV. Non appena l'ho disabilitato, il problema era sparito.

Ma vorrei davvero capire la causa di questo comportamento.

Volevo solo condividere la mia esperienza con te se qualcuno potesse avere lo stesso problema con MOODLE .

La nostra piattaforma moodle è stata improvvisamente molto lentamente, il cruscotto ha impiegato circa 2-3 volte più a caricare (fino a 6 secondi) rispetto al solito e di volta in volta alcune pagine non sono state caricate affatto (non un errore 404 ma una pagina vuota ). Nella Console degli strumenti per gli sviluppatori era visibile il seguente errore:net::ERR_INCOMPLETE_CHUNKED_ENCODING.

Cercando questo errore, sembra che Chrome sia il problema, ma abbiamo avuto il problema con vari browser. Dopo ore di ricerche e di confronto tra i database dei giorni precedenti, ho finalmente scoperto il problema, qualcuno ha attivato il monitoraggio degli eventi. Tuttavia, nel registro "Config modifiche", questa modifica non era visibile! La disattivazione del monitoraggio degli eventi ha finalmente risolto il problema: non erano state definite regole per il monitoraggio degli eventi.

Stiamo eseguendo Moodle 3.1.2+ con MariaDB e PHP 5.4.

Ciò stava accadendo su due diversi server client separati da diversi anni, utilizzando lo stesso codice che è stato distribuito su centinaia di altri server per quel periodo senza problemi.

Per questi client, è accaduto principalmente su script PHP con streaming HTML, ovvero pagine "Connessione: chiudi" in cui l'output è stato inviato al browser quando l'output è diventato disponibile.

Si è scoperto che la connessione tra il processo PHP e il server Web stava cadendo prematuramente, prima che lo script fosse completato e molto prima di qualsiasi timeout.

Il problema era opcache.fast_shutdown = 1 nel file php.ini principale. Questa direttiva è disabilitata per impostazione predefinita, ma sembra che alcuni amministratori di server credano che qui ci sia un aumento delle prestazioni. In tutti i miei test, non ho mai notato una differenza positiva usando questa impostazione. Nella mia esperienza, ha causato l'esecuzione di alcuni script in modo più lento e ha una terribile traccia di volte che entra nello spegnimento mentre lo script è ancora in esecuzione o addirittura alla fine dell'esecuzione mentre il web server sta ancora leggendo dal buffer. Esiste una vecchia segnalazione di bug del 2013, irrisolta a febbraio 2017, che potrebbe essere correlata: https://github.com/zendtech/ZendOptimizerPlus/issues/146

Ho visto apparire i seguenti errori a causa di questo ERR_INCOMPLETE_CHUNKED_ENCODING ERR_SPDY_PROTOCOL_ERROR A volte ci sono segfault correlativi registrati; a volte no.

Se si verifica uno dei due, controllare phpinfo e assicurarsi che opcache.fast_shutdown sia disabilitato.

Mi dispiace dirlo, non ho una risposta precisa per te. Ma ho riscontrato anche questo problema e, almeno nel mio caso, ho trovato un modo per aggirarlo. Quindi forse offrirà alcuni indizi a qualcun altro che sa di più su Php sotto il cofano.

Lo scenario è che ho un array passato a una funzione. Il contenuto di questo array viene utilizzato per produrre una stringa HTML da inviare di nuovo al browser, posizionandolo all'interno di una variabile globale che verrà successivamente stampata. (Questa funzione in realtà non sta restituendo nulla. Sloppy, lo so, ma non è questo il punto.) All'interno di questo array, tra le altre cose, ci sono un paio di elementi che portano, per riferimento, array associativi annidati che sono stati definiti al di fuori di questa funzione . Tramite il processo di eliminazione, ho scoperto che la manipolazione di qualsiasi elemento all'interno di questo array all'interno di questa funzione, referenziata o meno, incluso un tentativo di disinserire quegli elementi referenziati, porta a Chrome che getta un errore di rete :: ERR_INCOMPLETE_CHUNKED_ENCODING e non mostra alcun contenuto.

Solo riprogettando lo script per non applicare riferimenti agli elementi dell'array, le cose hanno ricominciato a funzionare normalmente. Sospetto che questo sia in realtà un bug di Php che ha qualcosa a che fare con la presenza degli elementi referenziati che scaricano le intestazioni della lunghezza del contenuto, ma non ne so davvero abbastanza per dirlo con certezza.

Ho avuto questo problema con un sito in Chrome e Firefox. Se avessi spento Avast Web Shield, sarebbe andato via. Mi sembra di essere riuscito a farlo funzionare con Web Shield in esecuzione aggiungendo un po 'di htaccess html5 boilerplate al mio file htaccess:

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

La mia correzione è:

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

ob_flush();

?>

Spero che questo possa aiutare qualcuno in futuro, e nel mio caso è un problema di Kaspersky ma la correzione sopra funziona alla grande :)

Nel mio caso stava accadendo durante la serializzazione json di un payload di ritorno API web: avevo un riferimento "circolare" nel mio modello Entity Framework, stavo restituendo un semplice oggetto grafico uno a molti, ma il bambino aveva un riferimento a il genitore, che apparentemente non piace al serializzatore json. Rimozione della proprietà sul figlio che faceva riferimento al genitore ha fatto il trucco.

Spero che questo aiuti qualcuno che potrebbe avere un problema simile.

Controlla il permesso della cartella nginx e imposta il permesso appache per quello:

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

Stavo ottenendo net::ERR_INCOMPLETE_CHUNKED_ENCODING, dopo un'attenta ispezione dei log degli errori del server, ho scoperto che era dovuto al timeout di esecuzione dello script PHP.

L'aggiunta di questa riga sopra lo script PHP l'ha risolto per me:

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

Rif: errore irreversibile: superamento del tempo di esecuzione massimo di 30 secondi

Per me è stato causato da spazio libero insufficiente sul disco rigido.

questo stava accadendo per me per una ragione completamente diversa. net :: ERR_INCOMPLETE_CHUNKED_ENCODING 200 quando ispeziono la pagina e vado alla scheda newtork, vedo che la pagina vendor.js non è stata caricata. Al momento del controllo sembra che la dimensione del file js sia grande ~ 6,5 mb. Quando mi sono reso conto che avevo bisogno di comprimere il js. Ho verificato che stavo usando il ng buildcomando per compilare. Invece quando l'ho usato ng build --prod --aot --vendor-chunk --common-chunk --delete-output-path --buildOptimizerha funzionato per me. Vedi https://github.com/angular/angular-cli/issues/9016

Bene. Non molto tempo fa ho anche incontrato questa domanda. E finalmente ottengo le soluzioni che affrontano davvero questo problema.

I miei sintomi problematici sono anche le pagine che non si caricano e scoprono che i dati JSON sono stati troncati casualmente.

Ecco le soluzioni che riassumo potrebbero aiutare a risolvere questo problema

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

Se ci sono dei loop o degli elementi che non esistono, devi affrontare questo problema.

Quando si esegue l'app su Chrome, la pagina è vuota e non risponde.

Inizio dello scenario:

Ambiente di sviluppo: MAC, STS 3.7.3, tc Pivotal Server 3.1, Spring MVC Web,

in $ {myObj.getfName ()}

Fine dello scenario:

Motivo del problema: la funzione getfName () non è definita su myObj.

Spero che ti aiuti.

suppongo che il server non stia gestendo correttamente la codifica di trasferimento a blocchi. Deve terminare i file a pezzi con un blocco terminale per indicare che l'intero file è stato trasferito, quindi il codice qui sotto potrebbe funzionare:

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

Nel mio caso è stata interrotta la configurazione dell'estensione php mysqlnd_ms sul server. La cosa divertente è che funzionava bene su richieste di breve durata. C'è stato un avviso nel registro degli errori del server, quindi l'abbiamo risolto rapidamente.

Questo sembra un problema comune con molteplici cause e soluzioni, quindi inserirò la mia risposta qui per chiunque ne abbia bisogno.

Stavo ottenendo la net::ERR_INCOMPLETE_CHUNKED_ENCODINGcombinazione Chrome, osx, php70, httpd24, ma lo stesso codice funzionava bene sul server di produzione.

Inizialmente ho modificato i registri regolari ma non è stato mostrato nulla. Un rapido ls -laterspettacolo è system.logstato l'ultimo file toccato in /var/log, e la coda che mi ha dato

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

Contenuto tra:

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

Un brew uninstall php70-mongodbed un httpd -k restarttutto più tardi ed era una navigazione tranquilla.

Nel mio caso era un problema di HTML. C'era '\ n' nella risposta json che causava il problema. Quindi l'ho rimosso.

Affascinante vedere quante diverse cause ci sono per questo problema!

Molti dicono che è un problema di Chrome, quindi ho provato Safari e ho ancora problemi. Quindi ho provato tutte le soluzioni in questo thread, inclusa la disattivazione di AVG Realtime Protection, senza fortuna.

Per me, il problema era il mio .htaccessfile. Tutto ciò che conteneva era FallbackResource index.php, ma quando l'ho rinominato in htaccess.txt, il mio problema è stato risolto.

Hmmm mi sono appena imbattuto in un problema simile ma con diversi motivi dietro ...

Sto usando Laravel Valet su un progetto PHP alla vaniglia con Laravel Mix . Quando ho aperto il sito in Chrome, stava generando net::ERR_INCOMPLETE_CHUNKED_ENCODINGerrori. (Se avessi il sito caricato sul protocollo HTTPS, l'errore sarebbe cambiato innet::ERR_SPDY_PROTOCOL_ERROR .)

Ho controllato il php.inieopcache non è stato abilitato. Ho scoperto che nel mio caso il problema era correlato al controllo delle versioni dei file delle risorse - per qualche motivo, non sembrava gradire una stringa di query nell'URL delle risorse (beh, stranamente, solo una in particolare?).

Ho rimosso mix.version()per l'ambiente locale e il sito si carica bene nel mio Chrome su entrambi i protocolli HTTP e HTTPS.

Nel contesto di un controller in Drupal 8 (Symfony Framework) questa soluzione ha funzionato per me:

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

Altrimenti l'intestazione della risposta 'Transfer-Encoding' ha ottenuto un valore 'chunked'. Questo potrebbe essere un problema per il browser Chrome.