Błąd Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING

Przez ostatnie dwa miesiące w konsoli programisty Chrome otrzymuję następujący błąd:

net::ERR_INCOMPLETE_CHUNKED_ENCODING

Objawy:

• Strony się nie ładują.
• Obcięte pliki CSS i JS.
• Strony wiszą.

Środowisko serwerowe:

• Apache 2.2.22
• PHP
• Ubuntu

To się dzieje ze mną na naszym wewnętrznym serwerze Apache. Nikomu to się nie przytrafia - tj. Żaden z naszych użytkowników nie ma tego problemu - ani nikt inny z naszego zespołu programistów.

Inne osoby uzyskują dostęp do tego samego serwera z dokładnie tą samą wersją Chrome. Próbowałem też wyłączyć wszystkie rozszerzenia i przeglądać w trybie incognito - bez skutku.

Użyłem przeglądarki Firefox i dzieje się dokładnie to samo. Obcięte pliki i tak dalej. Jedyną rzeczą jest to, że Firefox nie zgłasza żadnych błędów konsoli, więc musisz sprawdzić żądanie HTTP przez Firebug, aby zobaczyć problem.

Nagłówki odpowiedzi z 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

Podczas testowania udało mi się rozwiązać problem, wymuszając HTTP 1.0 w moim pliku htaccess:

SetEnv downgrade-1.0

To eliminuje problem. Jednak wymuszanie HTTP 1.0 przez HTTP 1.1 nie jest właściwym rozwiązaniem.

Aktualizacja : Ponieważ tylko ja mam ten problem, doszedłem do wniosku, że muszę poświęcić więcej czasu na zbadanie, czy był to problem po stronie klienta. Jeśli przejdę do ustawień Chrome i skorzystam z opcji „Przywróć domyślne”, problem zniknie na około 10-20 minut. Potem wraca.

OK. Przetestowałem to potrójnie i jestem w 100% pewien , że jest to spowodowane moim programem antywirusowym (ESET NOD32 ANTIVIRUS 5).

Za każdym razem, gdy wyłączam ochronę w czasie rzeczywistym, problem znika. Dzisiaj wyłączyłem ochronę w czasie rzeczywistym na 6-7 godzin i problem nigdy się nie pojawił.

Kilka chwil temu włączyłem go ponownie, ale problem pojawił się w ciągu minuty.

Dla pewności w ciągu ostatnich 24 godzin włączyłem i ponownie wyłączyłem ochronę w czasie rzeczywistym. Za każdym razem - wynik był taki sam.

Aktualizacja: spotkałem innego programistę, który miał dokładnie ten sam problem z ochroną w czasie rzeczywistym w swoim programie antywirusowym firmy Kaspersky. Wyłączył go i problem zniknął. ie Wydaje się, że ten problem nie ogranicza się do ESET.

Błąd próbuje powiedzieć, że Chrome został odcięty podczas wysyłania strony. Twój problem próbuje dowiedzieć się, dlaczego.

Najwyraźniej może to być znany problem dotyczący kilku wersji Chrome. O ile wiem, jest to problem z dużą wrażliwością tych wersji na długość treści wysyłanego fragmentu i wyrażony rozmiar tego fragmentu (mógłbym być daleko od tego). Krótko mówiąc, nieco niedoskonały problem z nagłówkami.

Z drugiej strony może się zdarzyć, że serwer nie wyśle ​​fragmentu terminala o długości 0. Które można naprawić za pomocą ob_flush();. Możliwe jest również, że Chrome (lub połączenie lub coś takiego) działa wolno. Więc kiedy połączenie jest zamknięte, strona nie jest jeszcze załadowana. Nie mam pojęcia, dlaczego tak się stało.

Oto odpowiedź paranoicznych programistów:

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

W Twoim przypadku może to być przypadek przekroczenia limitu czasu skryptu. Nie jestem pewien, dlaczego miałoby to wpływać tylko na Ciebie, ale może to wynikać z kilku warunków wyścigu? To całkowite przypuszczenie. Powinieneś móc to przetestować, wydłużając czas wykonywania skryptu.

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

Może to być również tak proste, jak trzeba zaktualizować instalację Chrome (ponieważ ten problem jest związany z Chrome).

• https://code.google.com/p/chromium/issues/detail?id=461213
• IIS i Chrome: nie udało się załadować zasobu: net :: ERR_INCOMPLETE_CHUNKED_ENCODING
• https://wordpress.org/support/topic/interface-issue-err_incomplete_chunked_encoding

UPDATE: Udało mi się odtworzyć ten błąd (w końcu), gdy został wyrzucony błąd krytyczny, podczas gdy PHP (na tym samym hoście lokalnym) buforowało wyjście . Wyobrażam sobie, że dane wyjściowe były zbyt mocno zniekształcone, aby były bardzo przydatne (nagłówki, ale mało treści lub jej brak).

W szczególności przypadkowo miałem swój kod rekurencyjnie wywołujący się, dopóki PHP słusznie się nie poddał. W związku z tym serwer nie wysłał fragmentu terminala o długości 0 - co było problemem, który zidentyfikowałem wcześniej.

Miałem ten problem. Znalazłem go po wypróbowaniu większości innych odpowiedzi na to pytanie. Było to spowodowane przez właściciela i niepoprawne uprawnienia /var/lib/nginxdo /var/lib/nginx/tmpkatalogu.

Katalog tmp jest używany przez fast-cgi do buforowania odpowiedzi podczas ich generowania, ale tylko wtedy, gdy mają one większy rozmiar niż określony. Tak więc problem jest sporadyczny i występuje tylko wtedy, gdy wygenerowana odpowiedź jest duża.

Sprawdź, nginx <host_name>.error_logczy masz problemy z uprawnieniami.

Aby to naprawić, upewnij się, że właścicielem i grupą /var/lib/nginxwszystkich podkatalogów jest nginx.

Poniższe informacje powinny rozwiązać ten problem dla każdego klienta.

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

Ale w moim przypadku następująca opcja była lepsza i również to naprawiła:

.htaccess:

php_value opcache.enable 0

OMG, rozwiązałem ten sam problem 5 minut temu. Spędziłem kilka godzin, aby znaleźć rozwiązanie. Na pierwszy rzut oka wyłączenie antywirusa rozwiązało problem w systemie Windows. Ale potem zauważyłem problem na innym komputerze z systemem Linux bez programu antywirusowego. Brak błędów w dziennikach Nginx. Moja uwsgipokazał coś o „Broken rura”, ale nie na wszystkich żądań. Wiesz co? Nie było miejsca na urządzeniu, które znalazłem po ponownym uruchomieniu serwera w dzienniku bazy danych i dfzatwierdziłem to. Jedynym wyjaśnieniem, dlaczego program antywirusowy został rozwiązany, jest to, że zapobiega on buforowaniu przeglądarki (powinien sprawdzać każde żądanie), ale przeglądarka z dziwnym zachowaniem może po prostu zignorować złą odpowiedź i wyświetlić buforowane odpowiedzi.

W moim przypadku miałem to, /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied)co prawdopodobnie spowodowało błąd Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING.

Musiałem go usunąć /usr/local/var/run/nginx/i pozwolić nginxowi utworzyć go ponownie.

$ 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

Jest to znany problem z Chrome. Według narzędzi do śledzenia błędów Chrome i Chromium nie ma na to uniwersalnego rozwiązania. Ten problem nie jest związany z typem i wersją serwera, występuje w przeglądarce Chrome.

Ustawienie Content-Encodingnagłówka, aby identityrozwiązać ten problem do mnie.

z developer.mozilla.org

tożsamość | Wskazuje funkcję tożsamości (tj. Brak kompresji ani modyfikacji).

Mogę więc zasugerować, że w niektórych przypadkach Chrome nie może poprawnie wykonać kompresji gzip.

Najłatwiejszym rozwiązaniem jest zwiększenie proxy_read_timeout dla ustawionej lokalizacji proxy do wyższej wartości (powiedzmy 120s) w pliku nginx.conf.

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

Znalazłem to rozwiązanie tutaj https://rijulaggarwal.wordpress.com/2018/01/10/atmosphere-long-polling-on-nginx-chunked-encoding-error/

Po prostu zacząłem mieć podobny problem. Zauważyłem, że dzieje się to tylko wtedy, gdy strona zawierała znaki UTF-8 o wartości porządkowej większej niż 255 (tj. Wielobajtowej).

Problemem okazał się sposób obliczania nagłówka Content-Length. Bazowy backend obliczał długość znaków, a nie długość bajtów. Wyłączenie nagłówków długości zawartości tymczasowo rozwiązało problem, dopóki nie mogłem naprawić systemu szablonów zaplecza.

Kiedy napotkałem ten błąd (podczas wykonywania połączenia AJAX z javascript); powodem była błędna odpowiedź administratora; zwracał JSON, który nie miał prawidłowego formatu.

Tutaj problemem był mój Avast AV. Jak tylko go wyłączyłem, problem zniknął.

Ale naprawdę chciałbym zrozumieć przyczynę tego zachowania.

Chciałem tylko podzielić się z tobą moim doświadczeniem, jeśli ktoś może mieć ten sam problem z MOODLE .

Nasza platforma Moodle nagle zaczęła się bardzo powoli ładować, pulpit nawigacyjny ładował się około 2-3 razy dłużej (do 6 sekund) niż zwykle i od czasu do czasu niektóre strony w ogóle się nie ładowały (nie błąd 404, ale pusta strona ). W konsoli narzędzi programistycznych widoczny był następujący błąd:net::ERR_INCOMPLETE_CHUNKED_ENCODING.

Szukając tego błędu, wygląda na to, że przyczyną problemu jest Chrome, ale mieliśmy problem z różnymi przeglądarkami. Po godzinach poszukiwań i porównań baz danych z dni, zanim w końcu znalazłem problem, ktoś włączył monitorowanie zdarzeń. Jednak w dzienniku „Zmiany konfiguracji” ta zmiana nie była widoczna! Wyłączenie monitorowania zdarzeń ostatecznie rozwiązało problem - nie mieliśmy zdefiniowanych reguł monitorowania zdarzeń.

Używamy Moodle 3.1.2+ z MariaDB i PHP 5.4.

Działo się to na dwóch różnych serwerach klientów, które dzieliło kilka lat, przy użyciu tego samego kodu, który został wdrożony na setkach innych serwerów przez ten czas bez problemu.

W przypadku tych klientów działo się to głównie w skryptach PHP, które miały przesyłanie strumieniowe HTML - to znaczy na stronach „Połączenie: zamknij”, na których dane wyjściowe były wysyłane do przeglądarki, gdy były dostępne.

Okazało się, że połączenie między procesem PHP a serwerem WWW było przerywane przedwcześnie, zanim skrypt został ukończony i na długo przed jakimkolwiek przekroczeniem limitu czasu.

Problem dotyczył opcache.fast_shutdown = 1 w głównym pliku php.ini. Ta dyrektywa jest domyślnie wyłączona, ale wydaje się, że niektórzy administratorzy serwerów uważają, że można tu uzyskać wzrost wydajności. We wszystkich moich testach nigdy nie zauważyłem pozytywnej różnicy przy tym ustawieniu. Z mojego doświadczenia wynika, że ​​spowodowało to, że niektóre skrypty wykonywały się wolniej i ma okropną historię przechodzenia czasami do zamykania, gdy skrypt jest nadal wykonywany, lub nawet pod koniec wykonywania, gdy serwer sieciowy nadal czyta z bufora. Istnieje stary raport o błędzie z 2013 r., Nierozwiązany od lutego 2017 r., Który może być powiązany: https://github.com/zendtech/ZendOptimizerPlus/issues/146

Widziałem następujące błędy pojawiające się z powodu tego ERR_INCOMPLETE_CHUNKED_ENCODING ERR_SPDY_PROTOCOL_ERROR Czasami są rejestrowane korelacyjne segfaults; czasami nie.

Jeśli napotkasz któryś z nich, sprawdź swoje phpinfo i upewnij się, że opcache.fast_shutdown jest wyłączony.

Przykro mi to mówić, nie mam dla ciebie dokładnej odpowiedzi. Ale napotkałem również ten problem i przynajmniej w moim przypadku znalazłem sposób na jego obejście. Może więc zaoferuje kilka wskazówek komuś, kto wie więcej o PHP pod maską.

Scenariusz jest taki, że mam tablicę przekazaną do funkcji. Zawartość tej tablicy jest używana do tworzenia ciągu HTML, który ma zostać wysłany z powrotem do przeglądarki, poprzez umieszczenie go w całości wewnątrz zmiennej globalnej, która jest później drukowana. (Ta funkcja w rzeczywistości niczego nie zwraca. Wiem, niechlujnie, ale to nie ma znaczenia). Wewnątrz tej tablicy znajduje się między innymi kilka elementów przenoszących, przez odniesienie, zagnieżdżone tablice asocjacyjne, które zostały zdefiniowane poza tą funkcją . Dzięki procesowi eliminacji odkryłem, że manipulacja dowolnym elementem w tej tablicy w ramach tej funkcji, do której odwołuje się lub nie, w tym próba usunięcia tych elementów, do których istnieją odwołania, powoduje, że Chrome wyrzuca błąd net :: ERR_INCOMPLETE_CHUNKED_ENCODING i nie wyświetla żadnej treści.

Dopiero przeprojektowanie skryptu, aby nie stosować odniesień do elementów tablicy, sprawiło, że wszystko zaczęło działać normalnie. Podejrzewam, że w rzeczywistości jest to błąd PHP mający coś wspólnego z obecnością elementów, do których się odwołuje, wyrzucających nagłówki długości treści, ale naprawdę nie wiem o tym wystarczająco dużo, aby powiedzieć na pewno.

Miałem ten problem z witryną w przeglądarce Chrome i Firefox. Jeśli wyłączyłem Avast Web Shield, zniknęło. Wydaje mi się, że udało mi się zmusić go do pracy z działającą Osłoną WWW, dodając część htaccess html5 boilerplate do mojego pliku 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>

Moja poprawka to:

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

ob_flush();

?>

Mam nadzieję, że pomoże to komuś w przyszłości, aw moim przypadku jest to problem z Kaspersky, ale powyższa poprawka działa świetnie :)

W moim przypadku działo się to podczas serializacji json ładunku zwrotnego interfejsu API sieci Web - w moim modelu Entity Framework miałem odwołanie `` cykliczne '', zwracałem prosty wykres obiektu jeden do wielu, ale dziecko miało odniesienie z powrotem do rodzic, który najwyraźniej nie lubi serializatora json. Usunięcie właściwości dziecka, które odnosiło się do rodzica, załatwiło sprawę.

Mam nadzieję, że pomoże to komuś, kto może mieć podobny problem.

Sprawdź uprawnienia do folderu nginx i ustaw dla tego uprawnienia do pliku appache:

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

Dostawałem net::ERR_INCOMPLETE_CHUNKED_ENCODING , po bliższej inspekcji dzienników błędów serwera stwierdziłem, że było to spowodowane przekroczeniem limitu czasu wykonywania skryptu PHP.

Dodanie tej linii do skryptu PHP rozwiązało to dla mnie:

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

Ref: Błąd krytyczny: przekroczono maksymalny czas wykonywania 30 sekund

U mnie było to spowodowane niewystarczającą ilością wolnego miejsca na dysku twardym.

wydarzyło się to dla mnie z zupełnie innego powodu. net :: ERR_INCOMPLETE_CHUNKED_ENCODING 200 Kiedy sprawdzam stronę i przechodzę do zakładki newtork, widzę, że nie udało się załadować strony vendor.js. Po sprawdzeniu wydaje się, że rozmiar pliku js jest duży ~ 6,5 mb. Wtedy zdałem sobie sprawę, że muszę skompresować plik js. Sprawdziłem, czy używam ng buildpolecenia do budowania. Zamiast tego, kiedy użyłem ng build --prod --aot --vendor-chunk --common-chunk --delete-output-path --buildOptimizer, zadziałało dla mnie. Zobacz https://github.com/angular/angular-cli/issues/9016

Dobrze. Niedawno spotkałem się z tym pytaniem. I wreszcie otrzymuję rozwiązania, które naprawdę rozwiązują ten problem.

Objawy mojego problemu to także brak ładowania stron i stwierdzenie, że dane json zostały losowo obcięte.

Oto rozwiązania, które podsumowałem, mogą pomóc rozwiązać ten problem

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

Jeśli istnieje jakaś pętla lub element, który nie istnieje, napotkasz ten problem.

Po uruchomieniu aplikacji w przeglądarce Chrome strona jest pusta i nie odpowiada.

Początek scenariusza:

Środowisko programistyczne: MAC, STS 3.7.3, tc Pivotal Server 3.1, Spring MVC Web,

w $ {myObj.getfName ()}

Koniec scenariusza:

Przyczyna problemu: funkcja getfName () nie jest zdefiniowana w myObj.

Mam nadzieję, że ci to pomoże.

przypuszczam, że serwer nie obsługuje poprawnie fragmentarycznego kodowania transferu. Musi terminować podzielone pliki z fragmentem terminala, aby wskazać, że cały plik został przesłany, więc poniższy kod może działać:

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

W moim przypadku była to zepsuta konfiguracja rozszerzenia php mysqlnd_ms na serwerze. Zabawne jest to, że działał dobrze w przypadku żądań o krótkim czasie trwania. W dzienniku błędów serwera pojawiło się ostrzeżenie, więc szybko to naprawiliśmy.

Wydaje się, że jest to częsty problem z wieloma przyczynami i rozwiązaniami, więc mam zamiar umieścić tutaj moją odpowiedź dla każdego, kto może tego wymagać.

Dostawałem net::ERR_INCOMPLETE_CHUNKED_ENCODING w Chrome, OSX, php70, httpd24 skojarzonej, ale ten sam kod ran porządku na serwerze produkcyjnym.

Początkowo śledziłem regularne dzienniki, ale tak naprawdę nic się nie pokazało. Szybko ls -laterpokazał system.logostatni dotknięty plik /var/logi śledzenie, które mi dało

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

Zawarte w:

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-mongodbi httpd -k restartpóźniej i wszystko poszło gładko.

W moim przypadku była to kwestia html. W odpowiedzi json znajdował się znak „\ n” powodujący problem. Więc to usunąłem.

Fascynujące jest zobaczyć, ile różnych przyczyn ma ten problem!

Wielu twierdzi, że jest to problem z Chrome, więc wypróbowałem Safari i nadal miałem problemy. Potem wypróbowałem wszystkie rozwiązania w tym wątku, w tym wyłączenie ochrony w czasie rzeczywistym AVG, bez powodzenia.

Dla mnie problemem był mój .htaccessplik. Zawierał wszystko FallbackResource index.php, ale kiedy zmieniłem jego nazwę na htaccess.txt, mój problem został rozwiązany.

Hmmm właśnie natknąłem się na podobny problem, ale z różnymi powodami ...

Używam Laravel Valet w waniliowym projekcie PHP z Laravel Mix . Kiedy otworzyłem stronę w Chrome, wyrzucała net::ERR_INCOMPLETE_CHUNKED_ENCODINGbłędy. (Gdybym miał witrynę załadowaną do protokołu HTTPS, błąd zmienił się na net::ERR_SPDY_PROTOCOL_ERROR).

Sprawdziłem php.iniiopcache nie był włączony. Zauważyłem, że w moim przypadku problem był związany z wersjonowaniem plików zasobów - z jakiegoś powodu nie podobał się ciąg zapytania w adresie URL zasobów (cóż, co dziwne, w szczególności tylko jeden?).

Usunąłem mix.version()dla środowiska lokalnego, a witryna ładuje się dobrze w moim Chrome na protokołach HTTP i HTTPS.

W kontekście kontrolera w Drupalu 8 (Symfony Framework) zadziałało takie rozwiązanie:

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

W przeciwnym razie nagłówek odpowiedzi „Transfer-Encoding” otrzymał wartość „chunked”. Może to być problem z przeglądarką Chrome.