Błąd Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING


140

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.


Zapomniałeś o hamulcu. To jest poprawne -> while ($ row = mysql_fetch_assoc ($ result))
JustAnotherSimpleProgrammer__ Kwietnia

@PHPMan nie skopiował i wklej go poprawnie. Naprawiono teraz. Chciałbym, żeby to była przyczyna.
Wayne Whitty

1
również trzeba wiedzieć, że kod HTML wygenerowany przez ten kod while($row = mysql_fetch_assoc($result))może zawierać zbyt wiele pustych wierszy, które powodują obcięcie przez przeglądarki internetowe
Halayem Anis

7
Ten błąd jest zgłaszany, jeśli klient nie otrzyma ostatniej porcji o długości 0 z fragmentarycznego transferu. Na twoim miejscu odpaliłbym Wiresharka i przechwyciłbym ruch TCP, aby zobaczyć, co się dzieje.
aergistal

2
Może to być spowodowane problemem z siecią, a nie problemem z aplikacją (zwłaszcza, że ​​jesteś jedyną osobą, która go ma). Dlatego prawdopodobnie powinieneś najpierw spróbować wykluczyć problem z siecią jako możliwą przyczynę, monitorując ruch, jak sugerował @aergistal.
VolenD

Odpowiedzi:


80

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.


1
Kiedy używasz programu antywirusowego i wysyłasz nagłówek zawartości, czy to działa? Jeśli problem polega na tym, że Eset + odwiedza twoją stronę z dowolnego adresu IP, dobrym pomysłem może być jego naprawienie. Dostarczenie nagłówka o długości treści nie zaszkodzi, kosztuje może 1 ms na żądanie.
twicejr

2
Z wieloletniego doświadczenia wynika, że ​​antywirusy powodują znacznie więcej szkody niż pożytku.
Shadow Wizard is Ear For You

1
Dla każdego, kto ma ten problem z Kaspersky, problemem jest funkcja „Wstaw skrypt do ruchu sieciowego”. Możesz to znaleźć w ustawieniach sieci.
Hele

2
AVAST ma ten sam problem ... Zrobiło się tak źle, że nie mogłem już nawet odwiedzać niektórych witryn. Wyłączyłem webscanning i wszystko wróciło do normalnego działania ...
patrick

4
Tak, Avast też był dla mnie problemem. W szczególności Script Scanningopcja w ramach Osłony WWW.
Juha Untinen

47

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).

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.


Nie wiem, ale to jest dla mnie bardzo przydatne: set_time_limit (30);
Zhang Buzz,

1
Zwiększenie limitu pamięci pomogło w mojej sprawie: ini_set ('memory_limit', '500M');
BenK

Problem występuje w rzeczywistości, gdy zamykasz połączenie bez opróżniania odpowiedzi. To powoduje, że chrome nie otrzymuje ostatniego bajtu strumienia. W vertx, wykonaj response.end () zamiast response.close ()
MUNGAI NJOROGE

31

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.


3
To samo tutaj, chownw / var / lib / nginx naprawiłem to za mnie 👍
Yoav Aharoni

2
To samo tutaj, ALE moja instalacja homebrew utworzyła katalog / usr / local / var / run / nginx / fastcgi_temp, któremu musiałem przyznać uprawnienia do odczytu / zapisu.
cjn

Miałem podobne problemy, ale w moim przypadku problemy z uprawnieniami były związane z innym katalogiem: / etc / nginx / proxy_temp / . Po naprawieniu tego, przynajmniej na razie, problem zniknął.
Shidersz

W moim przypadku problem wydawał się być związany z wygaśnięciem certyfikatu SSL.
dvlcube

18

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

1
To naprawdę naprawiło to dla mnie. Ładuję zawartość generowaną przez PHP na divach przez ajax i otrzymuję błąd Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING 2 razy z 3, gdy plik jest większy niż 2 MB. Dodanie Content-length napraw mój problem. Dziękuję Ci!
Adrian P.,

To rozwiązanie zadziałało dla nas, mając witrynę, w której angular czytał json ... w naszym przypadku był to php_flag opcache.enable Off w .htaccess. Wiedzieliśmy, że nie jest to związane z programem antywirusowym, ponieważ nawet na Macu mieliśmy ten problem. Dzięki!!
danielgc

Świetnie :) Czy serwer WWW działa w PHP 5.6? Przypuszczam, że aktualizacja do PHP 7 również rozwiąże problem. Przynajmniej takie jest moje doświadczenie teraz!
twicejr

To ^ ^ ^ Tysiąc razy to! Napotkałem ten problem w witrynie Drupal 8, którą tworzymy. Jak tylko ustawiłem go na agregację CSS i JS, zaczął mieć problem z ładowaniem stron administratora w Chrome. Żadnych problemów w przeglądarce Firefox.
Andrew Wasson,

jak to zrobić w aplikacji opartej na jsp-servlet wdrożonej na serwerze tomcat
Shubham Arya

14

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.


1
grzebałem przy tym problemie przez ostatnie 24 godziny, naprawdę mnie uratowałeś. Było tak z powodu pełnej partycji root, było to podczas mojej instalacji django, logi pgbouncer zapełniły partycję root. Dzięki stary
Anoop Ar

Uratował mnie! Moja partycja główna była pełna, dotyczy to również
Nginx-

6

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

4

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.



3

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.


3

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.


2

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

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


2

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.


2

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.


1

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 podobne doświadczenia z tym komunikatem o błędzie, jednak stwierdziłem, że w moim kodzie był błąd, który prawdopodobnie powinien był spowodować błąd braku pamięci, chociaż prawdopodobnie nie korzystałem z dodatkowej pamięci w ramach rekursji. W każdym razie myślę, że PHP cicho umiera bez opróżniania bufora wyjściowego i bez generowania żadnego błędu PHP.
odpal siekierą

1

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>

1

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 :)


1

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.


1

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

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


1

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


1

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


0

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

0

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.


0

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

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.


0

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.


0

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


0

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.


1
Co...? Mam to samo ... Ale jeśli nazwa zostanie zmieniona na htaccess.txt, czy nie powinna już działać?

Dokładnie. Lepszym pytaniem może być, dlaczego występują błędy obsługi pliku index.php? A dlaczego to powoduje?
musicin3d

0

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.


0

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.