Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING erro

Nos últimos dois meses, recebi o seguinte erro no console do desenvolvedor do Chrome:

net::ERR_INCOMPLETE_CHUNKED_ENCODING

Sintomas:

• Páginas não carregadas.
• Arquivos CSS e JS truncados.
• Páginas penduradas.

Ambiente do servidor:

• Apache 2.2.22
• PHP
• Ubuntu

Isso está acontecendo comigo em nosso servidor Apache interno. Isso não está acontecendo com mais ninguém - ou seja, nenhum de nossos usuários está enfrentando esse problema - nem mais ninguém na nossa equipe de desenvolvimento.

Outras pessoas estão acessando exatamente o mesmo servidor com a mesma versão do Chrome. Também tentei desativar todas as extensões e navegar no modo de navegação anônima - sem efeito.

Eu usei o Firefox e exatamente a mesma coisa está ocorrendo. Arquivos truncados e outros enfeites. A única coisa é que o Firefox não gera nenhum erro no console, então você precisa inspecionar a solicitação HTTP via Firebug para ver o problema.

Cabeçalhos de resposta do 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 o teste, consegui corrigir o problema forçando o HTTP 1.0 no meu arquivo htaccess:

SetEnv downgrade-1.0

Isso se livra do problema. No entanto, forçar o HTTP 1.0 sobre o HTTP 1.1 não é uma solução adequada.

Atualização : como sou o único com esse problema, concluí que precisava gastar mais tempo investigando se era um problema do lado do cliente. Se eu entrar nas configurações do Chrome e usar a opção "Restaurar para o padrão", o problema desaparecerá por cerca de 10 a 20 minutos. Então ele retorna.

ESTÁ BEM. Eu testei isso três vezes e tenho 100% de certeza de que está sendo causado pelo meu antivírus (ESET NOD32 ANTIVIRUS 5).

Sempre que desativo a proteção em tempo real, o problema desaparece. Hoje, deixei a proteção em tempo real desativada por 6-7 horas e o problema nunca ocorreu.

Alguns instantes atrás, liguei novamente, apenas para que o problema aparecesse em um minuto.

Nas últimas 24 horas, liguei e desliguei a proteção em tempo real, apenas para ter certeza. Cada vez - o resultado tem sido o mesmo.

Atualização: Encontrei outro desenvolvedor que tinha exatamente o mesmo problema com a proteção em tempo real em seu antivírus Kaspersky. Ele desativou e o problema desapareceu. ou seja, esse problema não parece estar limitado ao ESET.

O erro está tentando dizer que o Chrome foi cortado enquanto a página estava sendo enviada. Seu problema está tentando descobrir o porquê.

Aparentemente, esse pode ser um problema conhecido que afeta algumas versões do Chrome. Tanto quanto posso dizer, é uma questão dessas versões serem extremamente sensíveis ao tamanho do conteúdo enviado e ao tamanho expresso desse pedaço (eu poderia estar longe disso). Em suma, um problema de cabeçalhos um pouco imperfeito.

Por outro lado, pode ser que o servidor não envie o pedaço de comprimento 0 do terminal. O que pode ser corrigido com ob_flush();. Também é possível que o Chrome (ou conexão ou algo assim) esteja lento. Portanto, quando a conexão é fechada, a página ainda não está carregada. Não tenho idéia do por que isso pode acontecer.

Aqui está a resposta dos programadores paranóicos:

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

No seu caso, pode ser o caso do tempo limite do script. Não sei ao certo por que isso deve afetar apenas você, mas pode estar relacionado a várias condições de corrida? Essa é uma suposição total. Você deve poder testar isso estendendo o tempo de execução do script.

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

Também pode ser tão simples quanto você precisa atualizar a instalação do Chrome (pois esse problema é específico do Chrome).

• https://code.google.com/p/chromium/issues/detail?id=461213
• IIS e Chrome: falha ao carregar o recurso: net :: ERR_INCOMPLETE_CHUNKED_ENCODING
• https://wordpress.org/support/topic/interface-issue-err_incomplete_chunked_encoding

ATUALIZAÇÃO: Consegui replicar esse erro (finalmente) quando um erro fatal foi lançado enquanto o PHP (no mesmo host local) estava em buffer de saída . Imagino que a saída tenha sido muito mal interpretada para ser de muita utilidade (cabeçalhos, mas com pouco ou nenhum conteúdo).

Especificamente, acidentalmente tive meu código se chamando recursivamente até o PHP, com razão, desistir. Portanto, o servidor não enviou a parte do terminal com 0 comprimento - que foi o problema que identifiquei anteriormente.

Eu tive esse problema. Rastreado depois de tentar a maioria das outras respostas sobre esta questão. Foi causado pelo proprietário e pelas permissões /var/lib/nginxe, mais especificamente, pelo/var/lib/nginx/tmp diretório incorreto.

O diretório tmp é usado pelo fast-cgi para armazenar em cache as respostas conforme elas são geradas, mas somente se elas estiverem acima de um determinado tamanho. Portanto, o problema é intermitente e ocorre apenas quando a resposta gerada é grande.

Verifica a nginx <host_name>.error_log se você está tendo problemas de permissão.

Para corrigir, verifique se o proprietário, o grupo /var/lib/nginxe todos os subdiretórios são nginx.

O seguinte deve corrigi-lo para todos os clientes.

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

Mas no meu caso, a seguinte era uma opção melhor e a corrigia também:

.htaccess:

php_value opcache.enable 0

OMG, resolvi o mesmo problema há 5 minutos. Passei várias horas para encontrar uma solução. À primeira vista, desabilitar o problema resolvido por antivírus no Windows. Mas então eu notei problema em outro pc linux sem antivírus. Sem erros nos logs do nginx. Meu uwsgimostrou algo sobre "Tubo quebrado", mas não em todos os pedidos. Sabe o que? Não havia espaço no dispositivo, que encontrei ao reiniciar o servidor no log do banco de dados e o dfaprovou. A única explicação sobre por que o antivírus foi resolvido é que ele impede o cache do navegador (deve verificar todas as solicitações), mas o navegador com algum comportamento estranho pode simplesmente ignorar respostas ruins e mostrar respostas em cache.

No meu caso eu estava tendo /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied) que provavelmente estava resultando no erro net :: ERR_INCOMPLETE_CHUNKED_ENCODING do Chrome.

Eu tive que remover /usr/local/var/run/nginx/e deixar o nginx criá-lo novamente.

$ 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

É um problema conhecido do Chrome. De acordo com os rastreadores de bugs do Chrome e do Chromium, não existe uma solução universal para isso. Esse problema não está relacionado ao tipo e versão do servidor, mas no Chrome.

Definir Content-Encodingcabeçalho para identityresolver esse problema para mim.

de developer.mozilla.org

identidade | Indica a função de identidade (ou seja, sem compactação nem modificação).

Então, posso sugerir que, em alguns casos, o Chrome não pode executar a compactação gzip corretamente.

Eu apenas fiquei com um problema semelhante. E notei que isso estava acontecendo apenas quando a página continha caracteres UTF-8 com um valor ordinal maior que 255 (isto é, multibyte).

O que acabou sendo o problema foi como o cabeçalho Content-Length estava sendo calculado. O back-end subjacente era calcular o comprimento dos caracteres, em vez do comprimento dos bytes. Desativar cabeçalhos de tamanho de conteúdo corrigia o problema temporariamente até que eu pudesse corrigir o sistema de modelo de back-end.

A solução mais fácil é aumentar o proxy_read_timeout para o seu local de proxy definido para um valor mais alto (digamos 120s) no seu nginx.conf.

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

Encontrei esta solução aqui https://rijulaggarwal.wordpress.com/2018/01/10/atmosphere-long-polling-on-nginx-chunked-encoding-error/

Quando eu enfrentei este erro (ao fazer chamada AJAX a partir de javascript); o motivo foi que a resposta do controlador foi incorreta; estava retornando um JSON que não era de formato válido.

Aqui o problema foi o meu Avast AV. Assim que o desativei, o problema desapareceu.

Mas, eu realmente gostaria de entender a causa desse comportamento.

Eu só queria compartilhar minha experiência com você, se alguém tiver o mesmo problema com o MOODLE .

Nossa plataforma moodle ficou subitamente muito lenta, o painel demorou cerca de 2-3 vezes mais para carregar (até 6 segundos) do que o normal e, de tempos em tempos, algumas páginas não eram carregadas (não um erro 404, mas uma página em branco) ) No Developer Tools Console, o seguinte erro era visível:net::ERR_INCOMPLETE_CHUNKED_ENCODING.

Procurando esse erro, parece que o Chrome é o problema, mas tivemos o problema com vários navegadores. Depois de horas pesquisando e comparando os bancos de dados dos dias anteriores a finalmente encontrar o problema, alguém ativou o Monitoramento de Eventos. No entanto, no log "Config changes", essa alteração não estava visível! Desativando o Monitoramento de Eventos, finalmente resolvemos o problema - não tínhamos regras definidas para o monitoramento de eventos.

Estamos executando o Moodle 3.1.2+ com MariaDB e PHP 5.4.

Isso estava acontecendo em servidores de dois clientes diferentes, separados por vários anos, usando o mesmo código implantado em centenas de outros servidores para esse período sem problemas.

Para esses clientes, isso acontecia principalmente em scripts PHP com HTML de fluxo contínuo - ou seja, "Conexão: fechar" as páginas em que a saída era enviada ao navegador quando a saída ficou disponível.

Verificou-se que a conexão entre o processo PHP e o servidor da web estava caindo prematuramente, antes da conclusão do script e antes de qualquer tempo limite.

O problema foi opcache.fast_shutdown = 1 no arquivo principal do php.ini. Essa diretiva está desativada por padrão, mas parece que alguns administradores de servidor acreditam que haja um aumento de desempenho aqui. Em todos os meus testes, nunca notei uma diferença positiva usando essa configuração. Na minha experiência, isso fez com que alguns scripts fossem executados mais lentamente e tem um histórico terrível de algumas vezes entrar no desligamento enquanto o script ainda está em execução, ou mesmo no final da execução enquanto o servidor da Web ainda está lendo o buffer. Há um relatório de bug antigo de 2013, não resolvido em fevereiro de 2017, que pode estar relacionado: https://github.com/zendtech/ZendOptimizerPlus/issues/146

Vi os seguintes erros aparecerem devido a isso ERR_INCOMPLETE_CHUNKED_ENCODING ERR_SPDY_PROTOCOL_ERROR Às vezes, existem segmentos correlatos registrados; às vezes não.

Se você tiver um deles, verifique seu phpinfo e verifique se o opcache.fast_shutdown está desativado.

Lamento dizer que não tenho uma resposta precisa para você. Mas também encontrei esse problema e, pelo menos no meu caso, encontrei uma maneira de contorná-lo. Então, talvez isso ofereça algumas pistas para alguém que saiba mais sobre Php sob o capô.

O cenário é que eu tenho uma matriz passada para uma função. O conteúdo dessa matriz está sendo usado para produzir uma sequência HTML a ser enviada de volta ao navegador, colocando tudo dentro de uma variável global que será impressa posteriormente. (Essa função não está realmente retornando nada. Desleixado, eu sei, mas isso não vem ao caso.) Dentro dessa matriz, entre outras coisas, há alguns elementos carregando, por referência, matrizes associativas aninhadas que foram definidas fora dessa função . Por processo de eliminação, descobri que a manipulação de qualquer elemento dentro dessa matriz dentro desta função, referenciada ou não, incluindo uma tentativa de desarmar esses elementos referenciados, resulta no Chrome lançando um erro net :: ERR_INCOMPLETE_CHUNKED_ENCODING e exibindo nenhum conteúdo.

Somente reformulando o script para não aplicar referências aos elementos da matriz, as coisas começaram a funcionar normalmente novamente. Eu suspeito que este é realmente um bug do Php que tem algo a ver com a presença dos elementos referenciados, jogando fora os cabeçalhos de comprimento de conteúdo, mas eu realmente não sei o suficiente sobre isso para ter certeza.

Eu tive esse problema com um site no Chrome e Firefox. Se eu desligasse o Avast Web Shield, ele desapareceria. Parece que consegui fazê-lo funcionar com o Web Shield em execução, adicionando alguns dos html5 clichê htaccess ao meu arquivo 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>

Minha correção é:

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

ob_flush();

?>

Espero que isso ajude alguém no futuro, e no meu caso é um problema da Kaspersky, mas a correção acima funciona muito bem :)

No meu caso, isso acontecia durante a serialização json de uma carga útil de retorno da API da Web - eu tinha uma referência 'circular' no meu modelo do Entity Framework, estava retornando um gráfico simples de um para muitos, mas a criança tinha uma referência para o pai, que aparentemente o json serializer não gosta. A remoção da propriedade no filho que estava referenciando o pai fez o truque.

Espero que isso ajude alguém que possa ter um problema semelhante.

Verifique a permissão da pasta nginx e defina a permissão appache para isso:

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

Eu estava recebendo net::ERR_INCOMPLETE_CHUNKED_ENCODING, após uma inspeção mais detalhada dos logs de erro do servidor, descobri que isso era devido ao tempo limite da execução do script PHP.

Adicionar esta linha sobre o script PHP resolveu isso para mim:

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

Ref: Erro fatal: Tempo máximo de execução de 30 segundos excedido

Para mim, foi causado por espaço livre insuficiente no disco rígido.

isso estava acontecendo para mim por uma razão completamente diferente. net :: ERR_INCOMPLETE_CHUNKED_ENCODING 200 quando inspeciono a página e vou para a guia newtork, vejo que a página vendor.js falhou ao carregar. Após verificar, parece que o tamanho do arquivo js é grande ~ 6,5 mb.That quando eu percebi que eu precisava comprimir o js. Eu verifiquei que estava usando o ng buildcomando para construir. Em vez disso, quando usei ng build --prod --aot --vendor-chunk --common-chunk --delete-output-path --buildOptimizer, funcionou para mim. Veja https://github.com/angular/angular-cli/issues/9016

Bem. Há pouco tempo, eu também conheci essa pergunta. E, finalmente, recebo as soluções que realmente solucionam esse problema.

Os sintomas do meu problema também são as páginas que não estão sendo carregadas e os dados do json foram truncados aleatoriamente.

Aqui estão as soluções que eu resumo podem ajudar a resolver esse 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 houver algum loop ou item que não existe, você enfrentará esse problema.

Ao executar o aplicativo no Chrome, a página fica em branco e deixa de responder.

Início do cenário:

Ambiente de desenvolvimento: MAC, STS 3.7.3, tc Pivotal Server 3.1, Spring MVC Web,

em $ {myObj.getfName ()}

Fim do cenário:

Motivo do problema: a função getfName () não está definida no myObj.

Espero que ajude você.

Meu palpite é que o servidor não está manipulando corretamente a codificação de transferência em pedaços. Ele precisa finalizar um arquivo em pedaços com um pedaço de terminal para indicar que o arquivo inteiro foi transferido. Portanto, o código abaixo talvez funcione:

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

No meu caso, foi quebrada a configuração da extensão php mysqlnd_ms no servidor. O engraçado é que estava funcionando bem em solicitações de curta duração. Houve um aviso no log de erros do servidor, por isso o corrigimos rapidamente.

Isso parece ser um problema comum com várias causas e soluções, por isso vou colocar minha resposta aqui para quem precisar.

eu estava conseguindo net::ERR_INCOMPLETE_CHUNKED_ENCODING usando a combinação Chrome, osx, php70, httpd24, mas o mesmo código funcionou bem no servidor de produção.

Inicialmente, segui os logs regulares, mas nada realmente apareceu. Uma rápida ls -laterdemonstração system.logfoi o último arquivo tocado /var/loge o tailing que me deu

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

Contido em:

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-mongodbe httpd -k restartmais tarde e tudo foi tranquilo.

No meu caso, era questão de html. Houve '\ n' na resposta json causando o problema. Então eu removi isso.

É fascinante ver quantas causas diferentes existem para esse problema!

Muitos dizem que é um problema do Chrome, então tentei o Safari e ainda tinha problemas. Em seguida, tentei todas as soluções desse segmento, incluindo desativar meu AVG Realtime Protection, sem sorte.

Para mim, o problema era meu .htaccessarquivo. Tudo o que continha era FallbackResource index.php, mas quando o renomeei htaccess.txt, meu problema foi resolvido.

Hummm, acabei de me deparar com um problema semelhante, mas com diferentes razões por trás ...

Estou usando o Laravel Valet em um projeto PHP básico com o Laravel Mix . Quando abri o site no Chrome, ele estava gerando net::ERR_INCOMPLETE_CHUNKED_ENCODINGerros. (Se eu tivesse o site carregado no protocolo HTTPS, o erro mudaria paranet::ERR_SPDY_PROTOCOL_ERROR .)

Eu verifiquei o php.inieopcache não estava ativado. Descobri que, no meu caso, o problema estava relacionado à versão dos arquivos de ativos - por algum motivo, não parecia uma string de consulta na URL dos ativos (bem, curiosamente, apenas um em particular?).

Eu removi mix.version()o ambiente local e o site carrega muito bem no meu Chrome nos protocolos HTTP e HTTPS.

No contexto de um Controller no Drupal 8 (Symfony Framework), esta solução funcionou para mim:

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

Caso contrário, o cabeçalho de resposta 'Transfer-Encoding' terá um valor 'chunked'. Isso pode ser um problema para o navegador Chrome.