Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING hatası

Son iki aydır, Chrome'un geliştirici konsolunda aşağıdaki hatayı alıyorum:

net::ERR_INCOMPLETE_CHUNKED_ENCODING

Semptomlar:

• Sayfalar yüklenmiyor.
• Kesilmiş CSS ve JS dosyaları.
• Sayfalar asılı.

Sunucu ortamı:

• Apache 2.2.22
• PHP
• Ubuntu

Bu, şirket içi Apache sunucumuzda bana oluyor. Başka kimsenin başına gelmez - yani hiçbir kullanıcımız bu sorunu yaşamıyor - ne de geliştirme ekibimizdeki hiç kimse.

Diğer kişiler, Chrome'un aynı sürümüyle tam olarak aynı sunucuya erişiyor. Ayrıca tüm uzantıları devre dışı bırakmayı ve Gizli modda göz atmayı da denedim - hiçbir etkisi olmadı.

Firefox kullandım ve aynı şey oluyor. Kesilmiş dosyalar falan. Tek şey, Firefox'un herhangi bir konsol hatası oluşturmamasıdır, bu nedenle sorunu görmek için Firebug aracılığıyla HTTP isteğini incelemeniz gerekir.

Apache'den Yanıt Başlıkları:

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

Test ederken, htaccess dosyamda HTTP 1.0'ı zorlayarak sorunu çözebildim:

SetEnv downgrade-1.0

Bu problemden kurtulur. Ancak, HTTP 1.0'ı HTTP 1.1 üzerinden zorlamak uygun bir çözüm değildir.

Güncelleme : Bu sorunu yaşayan tek kişi ben olduğum için, istemci tarafında bir sorun olup olmadığını araştırmak için daha fazla zaman harcamam gerektiğini düşündüm. Chrome ayarlarına gidip "Varsayılana Geri Yükle" seçeneğini kullanırsam, sorun yaklaşık 10-20 dakika kaybolur . Sonra geri döner.

TAMAM. Bunu üç kez test ettim ve bunun anti-virüsümden (ESET NOD32 ANTIVIRUS 5) kaynaklandığından % 100 eminim .

Gerçek Zamanlı korumayı her devre dışı bıraktığımda sorun ortadan kalkıyor. Bugün Gerçek Zamanlı korumayı 6-7 saat kapalı bıraktım ve sorun hiç yaşanmadı.

Birkaç dakika önce, yalnızca sorunun bir dakika içinde ortaya çıkması için onu tekrar açtım.

Son 24 saat içinde, emin olmak için Gerçek Zamanlı korumayı tekrar açıp kapattım. Her seferinde - sonuç aynıydı.

Güncelleme: Kaspersky anti-virüsünde Gerçek Zamanlı korumayla tamamen aynı sorunu yaşayan başka bir geliştiriciyle karşılaştım. Devre dışı bıraktı ve sorun ortadan kalktı. yani Bu sorun ESET ile sınırlı görünmüyor.

Hata, sayfa gönderilirken Chrome'un kesildiğini söylemeye çalışıyor. Sorununuz nedenini anlamaya çalışıyor.

Görünüşe göre bu, Chrome'un birkaç sürümünü etkileyen bilinen bir sorun olabilir. Anlayabildiğim kadarıyla, bu sürümlerin, gönderilen yığının içerik uzunluğuna ve bu parçanın ifade edilen boyutuna büyük ölçüde duyarlı olması sorunu (bu konuda çok uzakta olabilirim). Kısacası, biraz kusurlu bir başlık sorunu.

Öte yandan, sunucu terminal 0 uzunluklu yığın göndermiyor olabilir. Hangisi ile düzeltilebilir ob_flush();. Chrome'un (veya bağlantının veya başka bir şeyin) yavaş olması da mümkündür. Yani bağlantı kapatıldığında sayfa henüz yüklenmemiş. Bunun neden olabileceği hakkında hiçbir fikrim yok.

İşte paranoyak programcıların cevabı:

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

Sizin durumunuzda, komut dosyasının zaman aşımına uğraması olabilir. Neden sadece sizi etkilemesi gerektiğinden emin değilim ama bir sürü yarış koşuluna bağlı olabilir mi? Bu tam bir tahmin. Komut dosyası yürütme süresini uzatarak bunu test edebilmelisiniz.

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

Ayrıca, Chrome yüklemenizi güncellemeniz gerektiği kadar basit olabilir (çünkü bu sorun Chrome'a ​​özgüdür).

• https://code.google.com/p/chromium/issues/detail?id=461213
• IIS ve Chrome: kaynak yüklenemedi: net :: ERR_INCOMPLETE_CHUNKED_ENCODING
• https://wordpress.org/support/topic/interface-issue-err_incomplete_chunked_encoding

GÜNCELLEME: PHP (aynı localhost'ta) çıktı arabelleği alırken ölümcül bir hata atıldığında bu hatayı (sonunda) çoğaltabildim . Çıktının çok fazla kullanılamayacak kadar kötü bir şekilde karıştırıldığını düşünüyorum (başlıklar ancak çok az içerik var veya hiç yok).

Spesifik olarak, yanlışlıkla PHP pes edene kadar kodumun kendini yinelemeli olarak çağırmasını sağladım. Bu nedenle, sunucu, daha önce tanımladığım sorun olan terminal 0 uzunluklu parçayı göndermedi.

Bu sorunu yaşadım. Bu sorudaki diğer yanıtların çoğunu denedikten sonra izini sürdüm. Bu, sahibi ve izinlerinden /var/lib/nginxve daha özel olarak/var/lib/nginx/tmp dizinin dizinin yanlış olmasıdır.

Tmp dizini, fast-cgi tarafından yanıtları üretilirken önbelleğe almak için kullanılır, ancak yalnızca belirli bir boyutun üzerindeyse. Dolayısıyla sorun aralıklarla ortaya çıkıyor ve yalnızca oluşturulan yanıt büyük olduğunda ortaya çıkıyor.

Kontrol nginx <host_name>.error_logEğer izin sorunları yaşıyorsanız görebilirsiniz.

Düzeltmek için, sahibinin ve grubunun /var/lib/nginxve tüm alt dizinlerin nginx olduğundan emin olun.

Aşağıdakiler her müşteri için düzeltmelidir.

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

Ancak benim durumumda aşağıdakiler daha iyi bir seçenekti ve aynı zamanda düzeltildi:

.htaccess:

php_value opcache.enable 0

OMG, 5 dakika önce aynı sorunu çözdüm. Bir çözüm bulmak için birkaç saat harcadım. İlk bakışta antivirüsün devre dışı bırakılması Windows'ta sorunu çözdü. Ama sonra antivirüs içermeyen diğer linux bilgisayarlarda sorun olduğunu fark ettim. Nginx günlüklerinde hata yok. Benim uwsgibütün istekleri "Kırık boru" değil yaklaşık gösterdi şey. Biliyor musun? Veritabanı günlüğünde sunucuyu yeniden başlattığımda bulduğum cihazda yer kalmadı ve bunu dfonayladı. Antivirüsün neden çözüldüğüne dair tek açıklama, tarayıcının önbelleğe alınmasını engellediğidir (her isteği kontrol etmelidir), ancak bazı garip davranışlara sahip tarayıcı, kötü yanıtı görmezden gelebilir ve önbelleğe alınmış yanıtları gösterebilir.

Benim durumumda /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied), muhtemelen Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING hatasıyla sonuçlanan yaşıyordum.

Kaldırmam /usr/local/var/run/nginx/ve nginx'in yeniden oluşturmasına izin vermem gerekiyordu.

$ 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

Bilinen Chrome sorunu. Chrome ve Chromium hata izleyicilerine göre bunun için evrensel bir çözüm yok. Bu sorun sunucu türü ve sürümüyle ilgili değildir, Chrome'da doğrudur.

Bu sorunu benim için çözmek için Content-Encodingüstbilgi ayarlamak identity.

dan developer.mozilla.org

kimlik | Kimlik işlevini gösterir (yani sıkıştırma veya değişiklik yok).

Bu nedenle, bazı durumlarda Chrome'un gzip sıkıştırmasını doğru şekilde gerçekleştiremeyeceğini söyleyebilirim.

Ben de benzer bir problem yaşarken baktım. Ve sadece sayfa 255'ten daha büyük bir sıra değerine sahip UTF-8 karakterleri içerdiğinde (yani çok bayt) gerçekleştiğini fark ettim.

Sorun, Content-Length başlığının nasıl hesaplandığıydı. Temel arka uç, bayt uzunluğu yerine hesaplama karakter uzunluğuydu. İçerik uzunluğu başlıklarını kapatmak, arka uç şablon sistemini düzeltene kadar sorunu geçici olarak çözdü.

En kolay çözüm, ayarladığınız proxy konumu için proxy_read_timeout değerini nginx.conf dosyanızda daha yüksek bir değere (120s diyelim) yükseltmektir.

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

Bu çözümü burada buldum https://rijulaggarwal.wordpress.com/2018/01/10/atmosphere-long-polling-on-nginx-chunked-encoding-error/

Bu hatayla karşılaştığımda (javascript'ten AJAX çağrısı yaparken); bunun nedeni, denetleyiciden gelen yanıtın hatalı olmasıydı; geçerli formatta olmayan bir JSON döndürüyordu.

Burada sorun benim Avast AV'imdi. Devre dışı bıraktığım anda sorun gitmişti.

Ama bu davranışın nedenini gerçekten anlamak isterim.

Birisinin MOODLE ile aynı sorunu yaşayıp yaşamayacağını sizinle paylaşmak istedim .

Moodle platformumuz aniden çok yavaşladı, gösterge panosunun yüklenmesi yaklaşık 2-3 kat daha uzun sürdü (6 saniyeye kadar) ve normalden daha uzun sürdü ve zaman zaman bazı sayfalar hiç yüklenmedi (404 hatası değil, boş bir sayfa ). Developer Tools Console'da aşağıdaki hata görüldü:net::ERR_INCOMPLETE_CHUNKED_ENCODING.

Bu hatayı ararken, sorunun Chrome olduğu anlaşılıyor, ancak çeşitli tarayıcılarda sorun yaşadık. Sorunu bulmadan önceki günlerde saatlerce araştırma yaptıktan ve veritabanlarını karşılaştırdıktan sonra, birisi Olay İzlemeyi açtı. Ancak, "Yapılandırma değişiklikleri" günlüğünde bu değişiklik görünmüyordu! Olay İzleme'yi kapatmak, sonunda sorunu çözdü - olay izleme için tanımlanmış hiçbir kuralımız yoktu.

MariaDB ve PHP 5.4 ile Moodle 3.1.2+ çalıştırıyoruz.

Bu, birkaç yıl arayla ayrılmış iki farklı istemcinin sunucularında, o zaman için yüzlerce başka sunucuda sorunsuzca dağıtılan aynı kodu kullanarak oluyordu.

Bu istemciler için, çoğunlukla HTML akışına sahip PHP betiklerinde - yani çıktı kullanılabilir hale geldikçe çıktının tarayıcıya gönderildiği "Bağlantı: kapat" sayfalarında meydana geldi.

PHP süreci ile web sunucusu arasındaki bağlantının, komut dosyası tamamlanmadan ve herhangi bir zaman aşımından çok önce, zamanından önce kesildiği ortaya çıktı.

Sorun, ana php.ini dosyasındaki opcache.fast_shutdown = 1 idi. Bu yönerge varsayılan olarak devre dışı bırakılmıştır, ancak bazı sunucu yöneticilerinin burada olması gereken bir performans artışı olduğuna inandıkları görülmektedir. Tüm testlerimde, bu ayarı kullanarak hiçbir zaman pozitif bir fark görmedim. Tecrübelerime göre, bazı komut dosyalarının gerçekten daha yavaş çalışmasına neden oldu ve bazen komut dosyası yürütülürken veya hatta web sunucusu hala arabellekten okurken yürütmenin sonunda kapanmaya girme konusunda korkunç bir geçmişe sahip. 2013 yılına ait, Şubat 2017 itibarıyla çözülmemiş eski bir hata raporu var ve bunlarla ilgili olabilir: https://github.com/zendtech/ZendOptimizerPlus/issues/146

Bu ERR_INCOMPLETE_CHUNKED_ENCODING ERR_SPDY_PROTOCOL_ERROR nedeniyle aşağıdaki hataların ortaya çıktığını gördüm Bazen ilişkili segment hataları günlüğe kaydediliyor; bazen değil.

Bunlardan herhangi birini yaşarsanız, phpinfo'nuzu kontrol edin ve opcache.fast_shutdown'un devre dışı bırakıldığından emin olun.

Üzgünüm, sana kesin bir cevabım yok. Ama ben de bu sorunla karşılaştım ve en azından benim durumumda bunun etrafında bir yol buldum. Bu yüzden belki de başlık altında Php hakkında daha fazla bilgi sahibi olan birine bazı ipuçları sunacaktır.

Senaryo, bir işleve geçirilen bir dizim var. Bu dizinin içeriği, daha sonra yazdırılacak olan global bir değişkenin içine yerleştirilerek tarayıcıya geri gönderilecek bir HTML dizesi oluşturmak için kullanılıyor. (Bu işlev aslında hiçbir şey döndürmüyor. Özensiz, biliyorum, ama konu bu değil.) Bu dizinin içinde, diğer şeylerin yanı sıra, bu işlevin dışında tanımlanan iç içe geçmiş ilişkisel dizileri referans olarak taşıyan birkaç öğe var. . Ortadan kaldırma süreciyle, başvurulan veya başvurulmayan bu işlev içindeki herhangi bir öğenin, başvurulan öğelerin ayarını kaldırma girişimi dahil olmak üzere, bu dizinin içindeki herhangi bir öğenin değiştirilmesinin, Chrome'un bir net :: ERR_INCOMPLETE_CHUNKED_ENCODING hatası atmasına ve hiçbir içerik göstermemesine neden olduğunu buldum.

Sadece komut dizisini ilk etapta dizi öğelerine başvurular uygulamayacak şekilde yeniden düzenleyerek işler normal şekilde yeniden çalışmaya başladı. Bunun aslında içerik uzunluğundaki başlıkları atan referans öğelerin varlığıyla ilgisi olan bir Php hatası olduğundan şüpheleniyorum, ancak bunun hakkında kesin olarak söyleyecek kadar bilgim yok.

Chrome ve Firefox'ta bir siteyle bu sorunu yaşadım. Avast Web Kalkanı'nı kapatırsam kayboldu. Htaccess dosyama bazı html5 boilerplate htaccess ekleyerek Web Kalkanı ile çalışmasını sağlamayı başardım:

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

Düzeltmem:

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

ob_flush();

?>

Umarım bu gelecekte birine yardımcı olur ve benim durumumda bu bir Kaspersky sorunu ancak yukarıdaki düzeltme harika çalışıyor :)

Benim durumumda, bir web api dönüş yükünün json serileştirmesi sırasında oluyordu - Entity Framework modelimde 'dairesel' bir referansım vardı, basit bire-çok nesne grafiğini geri döndürüyordum ancak çocuğun bir referansı vardı ebeveyn, görünüşe göre json serileştiricinin hoşuna gitmiyor. Ebeveyne başvuran çocuk üzerindeki mülkün kaldırılması hile yaptı.

Umarım bu, benzer bir sorunu olabilecek birine yardımcı olur.

Nginx klasör iznini kontrol edin ve bunun için appache iznini ayarlayın:

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

Ben başlamıştı net::ERR_INCOMPLETE_CHUNKED_ENCODINGben PHP yürütme zaman aşımı nedeniyle olduğunu tespit sunucu hatası günlüklerinin daha yakından incelemeye göre.

Bu satırı PHP betiğinin üstüne eklemek benim için çözdü:

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

Ref: Önemli hata: 30 saniyelik maksimum yürütme süresi aşıldı

Benim için bunun nedeni sabit diskteki yetersiz boş alandı.

bu benim için tamamen farklı bir nedenden dolayı oluyordu. net :: ERR_INCOMPLETE_CHUNKED_ENCODING 200 sayfayı inceleyip newtork sekmesine gittiğimde, vendor.js sayfasının yüklenemediğini görüyorum. Kontrol ettikten sonra js dosyasının boyutu büyük ~ 6.5 mb gibi görünüyor. Js'yi sıkıştırmam gerektiğini fark ettiğimde. ng buildOluşturmak için komut kullandığımı kontrol ettim . Bunun yerine, kullandığımda ng build --prod --aot --vendor-chunk --common-chunk --delete-output-path --buildOptimizerbenim için çalıştı. Bkz. Https://github.com/angular/angular-cli/issues/9016

İyi. Kısa bir süre önce bu soruyla da karşılaştım. Ve sonunda bu sorunu gerçekten ele alan çözümleri alıyorum.

Benim sorun belirtilerim de yüklenmeyen sayfalardır ve json verilerinin rastgele kesildiğini görüyorum.

İşte özetlediğim çözümler bu sorunu çözmeye yardımcı olabilir

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

Mevcut olmayan herhangi bir döngü veya öğe varsa, bu sorunla karşılaşırsınız.

Uygulamayı Chrome'da çalıştırırken sayfa boş ve yanıt vermiyor.

Senaryo Başlangıcı:

Geliştirme Ortamı: MAC, STS 3.7.3, tc Pivotal Server 3.1, Spring MVC Web,

$ {myObj.getfName ()} içinde

Senaryo Sonu:

Sorunun nedeni: getfName () işlevi myObj'de tanımlı değil.

Umarım size yardımcı olur.

benim tahminim sunucu parçalanmış aktarım kodlamasını doğru şekilde işlemiyor. Tüm dosyanın aktarıldığını belirtmek için parçalanmış dosyaları bir uçbirim öbeği ile sonlandırması gerekir.Bu nedenle aşağıdaki kod işe yarayabilir:

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

Benim durumumda, sunucudaki mysqlnd_ms php uzantısı için yapılandırma bozuktu. Komik olan şey, kısa süreli talepler üzerinde iyi çalışıyor olması. Sunucu hata günlüğünde bir uyarı vardı, bu yüzden hızlı bir şekilde düzelttik.

Bu, birden fazla nedeni ve çözümü olan yaygın bir sorun gibi görünüyor, bu nedenle, buna ihtiyaç duyan herkes için cevabımı buraya koyacağım.

Alıyordum net::ERR_INCOMPLETE_CHUNKED_ENCODING Chrome, osx, php70, httpd24 kombinasyon üzerinde, ancak üretim sunucusunda aynı kod koştu cezası.

Başlangıçta normal günlükleri takip ettim ama hiçbir şey gerçekten görünmedi. Hızlı bir ls -latergösteri system.log, en son dokunulan /var/logdosyaydı ve bu bana verdi

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

İçinde bulunanlar:

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

Bir brew uninstall php70-mongodbve bir httpd -k restartsonra ve her şey düzgün bir seyirdi.

Benim durumumda html sorunu vardı. Soruna neden olan json yanıtında '\ n' vardı. Ben de onu kaldırdım.

Bu sorunun kaç farklı nedeni olduğunu görmek büyüleyici!

Birçoğu bunun bir Chrome sorunu olduğunu söylüyor, bu yüzden Safari'yi denedim ve hala sorunlarım var. Ardından, AVG Realtime Protection'ımı kapatmak da dahil olmak üzere, bu konudaki tüm çözümleri denedim, şans yok.

Benim için sorun benim .htaccessdosyamdı. İçerdiği tek şey vardı FallbackResource index.php, ancak adını olarak yeniden adlandırdığımda htaccess.txtsorunum çözüldü.

Hmmm Ben de benzer bir sorunla karşılaştım ama arkasında farklı nedenlerle ...

Ben kullanıyorum laravel Valet ile vanilya PHP proje üzerinde laravel Mix . Siteyi Chrome'da açtığımda net::ERR_INCOMPLETE_CHUNKED_ENCODINGhata veriyordu. (Siteyi HTTPS protokolüne yüklediysem, hata olarak değişti net::ERR_SPDY_PROTOCOL_ERROR.)

Kontrol ettim php.inive opcacheetkinleştirilmedi. Benim durumumda sorunun varlık dosyalarının sürümlendirilmesiyle ilgili olduğunu buldum - bazı nedenlerden dolayı, varlıkların URL'sinde bir sorgu dizesi gibi görünmüyordu (peki, garip bir şekilde, özellikle sadece bir tane mi?).

mix.version()Yerel ortam için kaldırdım ve site hem HTTP hem de HTTPS protokollerinde Chrome'umda gayet iyi yükleniyor.

Drupal 8'deki (Symfony Framework) bir Denetleyici bağlamında bu çözüm benim için çalıştı:

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

Aksi takdirde, "Transfer-Encoding" yanıt başlığı "chunked" değerini aldı. Bu, Chrome tarayıcısı için bir sorun olabilir.