Mạng Chrome :: lỗi ERR_INCOMPLETE_CHUNKED_ENCODING

Trong hai tháng qua, tôi đã nhận được lỗi sau trên bảng điều khiển dành cho nhà phát triển của Chrome:

net::ERR_INCOMPLETE_CHUNKED_ENCODING

Triệu chứng:

• Trang không tải.
• Các tệp CSS và JS bị cắt bớt.
• Trang treo.

Môi trường máy chủ:

• Apache 2.2.22
• PHP
• Ubuntu

Điều này đang xảy ra với tôi trên máy chủ Apache nội bộ của chúng tôi. Điều này không xảy ra với bất kỳ ai khác - tức là Không ai trong số những người dùng của chúng tôi gặp phải vấn đề này - cũng không có ai khác trong nhóm nhà phát triển của chúng tôi.

Những người khác đang truy cập cùng một máy chủ với cùng một phiên bản Chrome chính xác. Tôi cũng đã thử vô hiệu hóa tất cả các tiện ích mở rộng và duyệt ở chế độ Ẩn danh - không có hiệu lực.

Tôi đã sử dụng Firefox và điều tương tự đang xảy ra. Các tập tin bị cắt và không có gì. Điều duy nhất là, Firefox không đưa ra bất kỳ lỗi nào trong bảng điều khiển, do đó bạn cần kiểm tra yêu cầu HTTP thông qua Fireorms để xem vấn đề.

Tiêu đề phản hồi từ 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

Trong khi thử nghiệm, tôi đã có thể khắc phục sự cố bằng cách buộc HTTP 1.0 trong tệp htaccess của mình:

SetEnv downgrade-1.0

Điều này được thoát khỏi vấn đề. Tuy nhiên, buộc HTTP 1.0 trên HTTP 1.1 không phải là một giải pháp thích hợp.

Cập nhật : Bởi vì tôi là người duy nhất gặp phải vấn đề này, tôi nhận ra rằng tôi cần dành nhiều thời gian hơn để điều tra xem đó có phải là vấn đề của khách hàng hay không. Nếu tôi truy cập cài đặt của Chrome và sử dụng tùy chọn "Khôi phục về mặc định", sự cố sẽ biến mất trong khoảng 10-20 phút. Rồi nó trở về.

ĐỒNG Ý. Tôi đã kiểm tra ba lần điều này và tôi chắc chắn 100% rằng nó đang được gây ra bởi phần mềm chống vi-rút của tôi (ESET NOD32 ANTIVIRUS 5).

Bất cứ khi nào tôi vô hiệu hóa bảo vệ thời gian thực, vấn đề sẽ biến mất. Hôm nay, tôi rời khỏi bảo vệ thời gian thực trong 6-7 giờ và vấn đề không bao giờ xảy ra.

Một vài phút trước, tôi bật lại, chỉ cho vấn đề nổi lên trong vòng một phút.

Trong suốt 24 giờ qua, tôi đã bật và tắt bảo vệ Thời gian thực một lần nữa, để chắc chắn. Mỗi lần - kết quả đều giống nhau.

Cập nhật: Tôi đã bắt gặp một nhà phát triển khác có cùng vấn đề với bảo vệ Thời gian thực trên chương trình chống vi-rút Kaspersky của anh ta. Ông vô hiệu hóa nó và vấn đề đã biến mất. tức là vấn đề này dường như không giới hạn ở ESET.

Lỗi đang cố nói rằng Chrome đã bị cắt trong khi trang đang được gửi. Vấn đề của bạn là cố gắng tìm hiểu tại sao.

Rõ ràng, đây có thể là sự cố đã biết ảnh hưởng đến một vài phiên bản Chrome. Theo như tôi có thể nói, vấn đề của các phiên bản này là rất nhạy cảm với độ dài nội dung của đoạn được gửi và kích thước được thể hiện của đoạn đó (tôi có thể bỏ xa phần đó). Trong ngắn hạn, một vấn đề tiêu đề hơi không hoàn hảo.

Mặt khác, có thể là máy chủ không gửi đoạn dữ liệu dài 0 đầu cuối. Mà có thể được sửa chữa với ob_flush();. Cũng có thể Chrome (hoặc kết nối hoặc thứ gì đó) đang bị chậm. Vì vậy, khi kết nối được đóng lại, trang vẫn chưa được tải. Tôi không biết tại sao điều này có thể xảy ra.

Dưới đây là câu trả lời của các lập trình viên hoang tưởng:

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

Trong trường hợp của bạn, nó có thể là một trường hợp hết thời gian của tập lệnh. Tôi không thực sự chắc chắn tại sao nó chỉ ảnh hưởng đến bạn nhưng nó có thể xuống đến một loạt các điều kiện chủng tộc? Đó là một phỏng đoán hoàn toàn. Bạn sẽ có thể kiểm tra điều này bằng cách kéo dài thời gian thực hiện tập lệnh.

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

Nó cũng có thể đơn giản như bạn cần cập nhật cài đặt Chrome của mình (vì vấn đề này là cụ thể của Chrome).

• https://code.google.com.vn/p/chromium/issues/detail?id=461213
• IIS & Chrome: không thể tải tài nguyên: net :: ERR_INCOMPLETE_CHUNKED_ENCODING
• https://wordpress.org/support/topic/interface-su-err_incomplete_chunked_encoding

CẬP NHẬT: Tôi đã có thể sao chép lỗi này (cuối cùng) khi một lỗi nghiêm trọng được đưa ra trong khi PHP (trên cùng một localhost) đang đệm đầu ra . Tôi tưởng tượng đầu ra quá tệ khi được sử dụng nhiều (tiêu đề nhưng ít hoặc không có nội dung).

Cụ thể, tôi đã vô tình có mã của mình gọi đệ quy cho đến khi PHP, đúng, đã từ bỏ. Do đó, máy chủ đã không gửi đoạn dữ liệu đầu cuối có độ dài 0 - đó là vấn đề tôi đã xác định trước đó.

Tôi đã có vấn đề này. Theo dõi nó sau khi thử hầu hết các câu trả lời khác cho câu hỏi này. Nó được gây ra bởi chủ sở hữu và quyền của /var/lib/nginxvà cụ thể hơn là /var/lib/nginx/tmpthư mục không chính xác.

Thư mục tmp được fast-cgi sử dụng để phản hồi bộ đệm khi chúng được tạo, nhưng chỉ khi chúng ở trên một kích thước nhất định. Vì vậy, vấn đề không liên tục và chỉ xảy ra khi phản hồi được tạo ra lớn.

Kiểm tra nginx <host_name>.error_logxem nếu bạn đang có vấn đề cho phép.

Để khắc phục, đảm bảo chủ sở hữu và nhóm /var/lib/nginxvà tất cả các thư mục con là nginx.

Sau đây nên sửa nó cho mọi khách hàng.

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

Nhưng trong trường hợp của tôi, đây là một lựa chọn tốt hơn và cũng đã sửa nó:

.htaccess:

php_value opcache.enable 0

OMG, tôi đã giải quyết vấn đề tương tự 5 phút trước. Tôi đã dành vài giờ để tìm một giải pháp. Ngay từ cái nhìn đầu tiên, vô hiệu hóa vấn đề chống vi-rút đã giải quyết trên Windows. Nhưng sau đó tôi nhận thấy vấn đề trên máy tính linux khác không có phần mềm diệt virus. Không có lỗi trong nhật ký nginx. My uwsgiđã cho thấy một cái gì đó về "Broken pipe" nhưng không phải trên tất cả các yêu cầu. Biết gì không? Nó không còn chỗ trống trên thiết bị, mà tôi tìm thấy khi khởi động lại máy chủ trên Nhật ký cơ sở dữ liệu và dfđã phê duyệt điều này. Chỉ giải thích về lý do tại sao phần mềm chống vi-rút được giải quyết là nó ngăn bộ nhớ đệm của trình duyệt (cần kiểm tra mọi yêu cầu), nhưng trình duyệt có một số hành vi lạ có thể đơn giản bỏ qua phản hồi xấu và hiển thị phản hồi được lưu trong bộ nhớ cache.

Trong trường hợp của tôi, tôi đã gặp phải /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied)lỗi Chrome Chrome :: ERR_INCOMPLETE_CHUNKED_ENCODING.

Tôi đã phải loại bỏ /usr/local/var/run/nginx/và để nginx tạo lại nó.

$ 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

Được biết vấn đề Chrome. Theo trình theo dõi lỗi của Chrome và Chromium, không có giải pháp chung nào cho việc này. Vấn đề này không liên quan đến loại máy chủ và phiên bản, nó có ngay trong Chrome.

Đặt Content-Encodingtiêu đề để identitygiải quyết vấn đề này cho tôi.

từ developer.mozilla.org

danh tính | Cho biết chức năng nhận dạng (tức là không nén, cũng không sửa đổi).

Vì vậy, tôi có thể đề xuất rằng trong một số trường hợp, Chrome không thể thực hiện nén gzip chính xác.

Tôi chỉ nhìn chằm chằm có một vấn đề tương tự. Và nhận thấy nó chỉ xảy ra khi trang chứa các ký tự UTF-8 có giá trị thứ tự lớn hơn 255 (tức là đa bào).

Điều cuối cùng là vấn đề là cách tính tiêu đề Độ dài nội dung. Phần cuối phụ là tính toán độ dài ký tự, thay vì độ dài byte. Tắt các tiêu đề có độ dài nội dung tạm thời khắc phục sự cố cho đến khi tôi có thể khắc phục hệ thống mẫu phía sau.

Giải pháp đơn giản nhất là tăng proxy_read_timeout cho vị trí proxy được đặt của bạn lên giá trị cao hơn (giả sử là 120 giây) trong nginx.conf của bạn.

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

Tôi tìm thấy giải pháp này tại đây https://rijulaggarwal.wordpress.com/2018/01/10/atherehere-long-polling-on-nginx-chunked-encoding-error/

Khi tôi gặp phải lỗi này (trong khi thực hiện cuộc gọi AJAX từ javascript); lý do là phản hồi từ bộ điều khiển là sai lầm; nó đã trả về một JSON không có định dạng hợp lệ.

Vấn đề là Avast AV của tôi. Ngay sau khi tôi vô hiệu hóa nó, vấn đề đã biến mất.

Nhưng, tôi thực sự muốn hiểu nguyên nhân của hành vi này.

Tôi chỉ muốn chia sẻ kinh nghiệm của tôi với bạn nếu ai đó có thể có cùng vấn đề với MOODLE .

Nền tảng moodle của chúng tôi đột nhiên rất chậm, bảng điều khiển mất thời gian tải khoảng 2-3 lần (tối đa 6 giây) sau đó thông thường và đôi khi một số trang không được tải (không phải lỗi 404 mà là trang trống ). Trong Bảng điều khiển công cụ dành cho nhà phát triển, có thể thấy lỗi sau:net::ERR_INCOMPLETE_CHUNKED_ENCODING.

Tìm kiếm lỗi này, có vẻ như Chrome là vấn đề, nhưng chúng tôi đã gặp sự cố với các trình duyệt khác nhau. Sau nhiều giờ nghiên cứu và so sánh các cơ sở dữ liệu từ những ngày trước khi tôi tìm thấy sự cố, ai đó đã bật Trình theo dõi sự kiện. Tuy nhiên, trong nhật ký "Cấu hình thay đổi", thay đổi này không hiển thị! Tắt giám sát sự kiện, cuối cùng đã giải quyết vấn đề - chúng tôi không có quy tắc nào được xác định cho giám sát sự kiện.

Chúng tôi đang chạy Moodle 3.1.2+ với MariaDB và PHP 5.4.

Điều này đã xảy ra trên hai máy chủ của các máy khách khác nhau cách nhau vài năm, sử dụng cùng một mã được triển khai trên hàng trăm máy chủ khác trong thời gian đó mà không gặp sự cố.

Đối với những khách hàng này, điều đó đã xảy ra chủ yếu trên các tập lệnh PHP đã phát trực tuyến HTML - nghĩa là các trang "Kết nối: đóng" nơi đầu ra được gửi tới trình duyệt khi đầu ra có sẵn.

Hóa ra, kết nối giữa quy trình PHP và máy chủ web đã bị hủy sớm, trước khi tập lệnh hoàn thành và cách trước bất kỳ thời gian chờ nào.

Vấn đề là opcache.fast_shutdown = 1 trong tệp php.ini chính. Lệnh này bị tắt theo mặc định, nhưng có vẻ như một số quản trị viên máy chủ tin rằng có một sự tăng cường hiệu suất cần có ở đây. Trong tất cả các thử nghiệm của tôi, tôi chưa bao giờ ghi nhận sự khác biệt tích cực khi sử dụng cài đặt này. Theo kinh nghiệm của tôi, nó đã khiến một số tập lệnh thực sự hoạt động chậm hơn và có một hồ sơ theo dõi khủng khiếp đôi khi bị tắt máy trong khi tập lệnh vẫn đang thực thi hoặc thậm chí khi kết thúc thực thi trong khi máy chủ web vẫn đọc từ bộ đệm. Có một báo cáo lỗi cũ từ năm 2013, chưa được giải quyết kể từ tháng 2 năm 2017, có thể liên quan: https://github.com/zendtech/ZendOptimizerPlus/issues/146

Tôi đã thấy các lỗi sau xuất hiện do ERR_INCOMPLETE_CHUNKED_ENCODING ERRinksDY_PROTOCOL_ERROR Đôi khi có các phân tách tương quan được ghi lại; đôi khi không.

Nếu bạn gặp phải một trong hai, hãy kiểm tra phpinfo của bạn và đảm bảo opcache.fast_shutdown bị tắt.

Tôi rất tiếc phải nói rằng, tôi không có câu trả lời chính xác cho bạn. Nhưng tôi cũng đã gặp phải vấn đề này, và, ít nhất là trong trường hợp của tôi, đã tìm ra cách khắc phục nó. Vì vậy, có lẽ nó sẽ cung cấp một số manh mối cho người khác biết nhiều hơn về Php dưới mui xe.

Kịch bản là, tôi có một mảng được truyền cho một hàm. Nội dung của mảng này đang được sử dụng để tạo ra một chuỗi HTML được gửi trở lại trình duyệt, bằng cách đặt tất cả vào bên trong một biến toàn cục được in sau đó. (Hàm này thực sự không trả về bất cứ thứ gì. Sloppy, tôi biết, nhưng bên cạnh vấn đề.) Bên trong mảng này, trong số những thứ khác, có một vài phần tử mang, theo tham chiếu, các mảng kết hợp lồng nhau được xác định bên ngoài hàm này . Bằng cách loại bỏ quá trình, tôi thấy rằng thao tác của bất kỳ phần tử nào trong mảng này trong hàm này, được tham chiếu hay không, bao gồm cả nỗ lực bỏ đặt các phần tử được tham chiếu đó, dẫn đến Chrome ném một lỗi :: ERR_INCOMPLETE_CHUNKED_ENCODING và không hiển thị nội dung.

Chỉ bằng cách sử dụng lại công cụ tập lệnh để không áp dụng các tham chiếu cho các phần tử mảng ở vị trí đầu tiên, mọi thứ mới bắt đầu hoạt động bình thường trở lại. Tôi nghi ngờ đây thực sự là một lỗi Php có liên quan đến sự hiện diện của các yếu tố được tham chiếu loại bỏ các tiêu đề có độ dài nội dung, nhưng tôi thực sự không biết đủ về điều này để nói chắc chắn.

Tôi gặp vấn đề này với một trang web trong Chrome và Firefox. Nếu tôi tắt Avast Web Shield, nó sẽ biến mất. Tôi dường như đã quản lý để làm cho nó hoạt động với Web Shield đang chạy bằng cách thêm một số htaccess soạn sẵn html5 vào tệp htaccess của tôi:

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

Cách khắc phục của tôi là:

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

ob_flush();

?>

Hy vọng điều này sẽ giúp được ai đó trong tương lai và trong trường hợp của tôi là sự cố của Kaspersky nhưng cách khắc phục ở trên hoạt động rất tốt :)

Trong trường hợp của tôi, điều đó đã xảy ra trong quá trình tuần tự hóa json của tải trọng trả lại api web - Tôi đã có một tham chiếu 'vòng tròn' trong mô hình Entity Framework của mình, tôi đã trả lại một biểu đồ đối tượng một-nhiều đơn giản nhưng đứa trẻ đã tham chiếu lại cha mẹ, mà rõ ràng là serial serial json không thích. Loại bỏ tài sản trên đứa trẻ đang giới thiệu cha mẹ đã thực hiện thủ thuật.

Hy vọng điều này sẽ giúp ai đó có thể có một vấn đề tương tự.

Kiểm tra quyền thư mục nginx và đặt quyền appache cho điều đó:

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

Tôi đã nhận được net::ERR_INCOMPLETE_CHUNKED_ENCODING, khi kiểm tra kỹ hơn các bản ghi lỗi máy chủ, tôi thấy rằng đó là do thời gian thực thi tập lệnh PHP.

Thêm dòng này vào đầu tập lệnh PHP đã giải quyết nó cho tôi:

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

Tham chiếu: Lỗi nghiêm trọng: Thời gian thực hiện tối đa là 30 giây

Đối với tôi, đó là do không đủ dung lượng trống trên ổ cứng.

điều này đã xảy ra với tôi vì một lý do khác nhau hoàn toàn. net :: ERR_INCOMPLETE_CHUNKED_ENCODING 200 khi tôi kiểm tra trang và chuyển đến tab newtork, tôi thấy rằng trang Vend.js đã không tải được. Khi kiểm tra có vẻ như kích thước của tệp js lớn ~ 6,5 mb. Đó là khi tôi nhận ra rằng tôi cần phải nén js. Tôi đã kiểm tra rằng tôi đang sử dụng ng buildlệnh để xây dựng. Thay vào đó khi tôi sử dụng ng build --prod --aot --vendor-chunk --common-chunk --delete-output-path --buildOptimizernó hoạt động cho tôi.see https://github.com/angular/angular-cli/issues/9016

Tốt. Cách đây không lâu tôi cũng đã gặp câu hỏi này. Và cuối cùng tôi nhận được các giải pháp thực sự giải quyết vấn đề này.

Các triệu chứng vấn đề của tôi cũng là các trang không tải và tìm thấy dữ liệu json đã bị cắt ngắn ngẫu nhiên.

Dưới đây là các giải pháp mà tôi tóm tắt có thể giúp giải quyết vấn đề này

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

Nếu có bất kỳ vòng lặp hoặc mục nào không tồn tại thì bạn phải đối mặt với vấn đề này.

Khi chạy Ứng dụng trên Chrome, trang trống và không phản hồi.

Kịch bản bắt đầu:

Môi trường phát triển: MAC, STS 3.7.3, tc Pivotal Server 3.1, Spring MVC Web,

trong $ {myObj.getfName ()}

Kết thúc kịch bản:

Lý do của vấn đề: hàm getfName () không được xác định trên myObj.

Hy vọng nó sẽ giúp bạn.

Tôi đoán là máy chủ không xử lý chính xác mã hóa chuyển khối. Nó cần thiết bị đầu cuối một tệp chunk với một đoạn cuối để cho biết toàn bộ tệp đã được chuyển. Vì vậy, mã dưới đây có thể hoạt động:

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

Trong trường hợp của tôi, nó đã bị hỏng cấu hình cho phần mở rộng php mysqlnd_ms trên máy chủ. Điều buồn cười là nó đã hoạt động tốt trên các yêu cầu với thời gian ngắn. Có một cảnh báo trong nhật ký lỗi máy chủ, vì vậy chúng tôi đã sửa nó nhanh chóng.

Đây có vẻ như là một vấn đề phổ biến với nhiều nguyên nhân và giải pháp, vì vậy tôi sẽ đặt câu trả lời của mình ở đây cho bất kỳ ai có thể yêu cầu.

Tôi đã nhận được net::ERR_INCOMPLETE_CHUNKED_ENCODING kết hợp Chrome, osx, php70, httpd24, nhưng cùng một mã chạy tốt trên máy chủ sản xuất.

Tôi ban đầu kéo theo các bản ghi thông thường nhưng không có gì thực sự xuất hiện. Một cách nhanh chóng ls -latercho thấy system.loglà tập tin cảm ứng mới nhất trong /var/logvà đuôi cho tôi

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

Chứa trong:

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-mongodbvà httpd -k restartsau đó và mọi thứ đều thuận buồm xuôi gió.

Trong trường hợp của tôi, đó là vấn đề của html. Có '\ n' trong phản hồi json gây ra vấn đề. Vì vậy, tôi đã loại bỏ điều đó.

Hấp dẫn để xem có bao nhiêu nguyên nhân khác nhau cho vấn đề này!

Nhiều người nói đó là sự cố của Chrome, vì vậy tôi đã dùng thử Safari và vẫn gặp sự cố. Sau đó, đã thử tất cả các giải pháp trong chuỗi này, bao gồm tắt Bảo vệ thời gian thực AVG của tôi, không gặp may.

Đối với tôi, vấn đề là .htaccesstập tin của tôi . Tất cả nó chứa là FallbackResource index.php, nhưng khi tôi đổi tên thành htaccess.txt, vấn đề của tôi đã được giải quyết.

Hmmm, tôi chỉ vấp phải một vấn đề tương tự nhưng với những lý do khác nhau đằng sau ...

Tôi đang sử dụng Laravel Valet trong một dự án PHP vanilla với Laravel Mix . Khi tôi mở trang web trong Chrome, nó đã bị net::ERR_INCOMPLETE_CHUNKED_ENCODINGlỗi. (Nếu tôi đã tải trang web trên giao thức HTTPS, lỗi đã thay đổi thành net::ERR_SPDY_PROTOCOL_ERROR.)

Tôi đã kiểm tra php.inivà opcachekhông được kích hoạt. Tôi thấy rằng trong trường hợp của tôi, vấn đề liên quan đến việc phiên bản các tệp tài sản - vì một số lý do, nó dường như không thích một chuỗi truy vấn trong URL của tài sản (cụ thể, có đủ kỳ lạ không, chỉ là một đặc biệt?).

Tôi đã xóa mix.version()cho môi trường cục bộ và trang web tải tốt trong Chrome của tôi trên cả giao thức HTTP và HTTPS.

Trong bối cảnh Bộ điều khiển trong Drupal 8 (Khung Symfony), giải pháp này hiệu quả với tôi:

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

Mặt khác, tiêu đề phản hồi 'Mã hóa chuyển' có giá trị 'chunked'. Đây có thể là một vấn đề đối với trình duyệt Chrome.