Mạng :: ERR_HTTP2_PROTOCOL_ERROR nói về cái gì?

Tôi hiện đang làm việc trên một trang web, điều này gây ra net::ERR_HTTP2_PROTOCOL_ERROR 200lỗi trên Google Chrome. Tôi không chắc chắn chính xác những gì có thể gây ra lỗi này, tôi chỉ nhận thấy nó chỉ bật ra khi truy cập trang web trong HTTPS. Tôi không thể chắc chắn 100% nó có liên quan, nhưng có vẻ như nó ngăn chặn javascript được thực thi đúng cách.

Chẳng hạn, kịch bản sau đây xảy ra:

1. Tôi đang truy cập trang web trong HTTPS

2. Nguồn cấp dữ liệu Twitter của tôi được tích hợp qua https://publish.twitter.com hoàn toàn không được tải

3. Tôi có thể nhận thấy trong bảng điều khiển ERR_HTTP2_PROTOCOL_ERROR

4. Nếu tôi xóa mã để tải nguồn cấp dữ liệu Twitter, lỗi vẫn còn

5. Nếu tôi truy cập trang web bằng HTTP, nguồn cấp dữ liệu Twitter sẽ xuất hiện và lỗi sẽ biến mất

Google Chrome là trình duyệt web duy nhất gây ra lỗi: nó hoạt động tốt trên cả Edge và Firefox. (NB: Tôi đã thử với Safari và tôi gặp kcferrordomaincfnetwork 303lỗi tương tự )

Tôi đã tự hỏi liệu nó có thể liên quan đến tiêu đề được máy chủ trả về hay không vì có lỗi '200' này và một trang 404/500 không kích hoạt bất cứ điều gì.

Điều đó là lỗi không được ghi nhận ở tất cả. Tìm kiếm Google cho tôi rất ít kết quả. Hơn nữa, tôi nhận thấy nó xuất hiện trên các bản phát hành Google Chrome gần đây; lỗi không xuất hiện trên v.64.X, nhưng nó xảy ra trên v.75 + (bất kể hệ điều hành; tôi đang làm việc trên Mac tho).

Bất kỳ manh mối tại thời điểm này để điều tra sẽ được vui mừng đánh giá cao!

Cảm ơn trước.

Tristan

Chỉnh sửa 1: Có thể liên quan đến Trang web OK trên Firefox nhưng không phải trên Safari (kCFErrorDomainCFNetwork lỗi 303) cũng không phải Chrome (net :: ERRinksDY_PROTOCOL_ERROR)

Chỉnh sửa 2: Kết quả từ các cuộc điều tra tiếp theo như sau:

• lỗi không xuất hiện trên cùng một trang nếu máy chủ trả về 404 thay vì 2XX
• lỗi không bật trên cục bộ với chứng chỉ HTTPS
• lỗi xuất hiện trên một máy chủ khác (cả hai đều là OVH), sử dụng chứng chỉ khác
• lỗi xuất hiện bất kể phiên bản PHP nào được sử dụng, từ 5.6 đến 7.3 (khung được sử dụng: Cakephp 2.10)

Chỉnh sửa 3: Theo yêu cầu, bên dưới là tiêu đề được trả về cho ressource không thành công, đó là toàn bộ trang web. Ngay cả khi lỗi đang kích hoạt trên mỗi trang có tiêu đề HTTP 200, các trang đó luôn tải trên trình duyệt của khách hàng, nhưng đôi khi thiếu một yếu tố (trong ví dụ của tôi, nguồn cấp dữ liệu Twitter bên ngoài). Mọi tài sản khác trên tab Mạng đều có lợi nhuận thành công, ngoại trừ toàn bộ tài liệu.

Tiêu đề Google Chrome (có lỗi):

Tiêu đề Firefox (không có lỗi):

Một curl --head --http2yêu cầu trong bảng điều khiển trả về thành công sau:

HTTP/2 200 
date: Fri, 04 Oct 2019 08:04:51 GMT
content-type: text/html; charset=UTF-8
content-length: 127089
set-cookie: SERVERID31396=2341116; path=/; max-age=900
server: Apache
x-powered-by: PHP/7.2
set-cookie: xxxxx=0919c5563fc87d601ab99e2f85d4217d; expires=Fri, 04-Oct-2019 12:04:51 GMT; Max-Age=14400; path=/; secure; HttpOnly
vary: Accept-Encoding

Chỉnh sửa 4: Cố gắng đi sâu hơn với chrome: // net-export / và https://netlog-viewer.appspot.com công cụ đang cho tôi biết yêu cầu kết thúc bằng RST_STREAM:

t=123354 [st=5170]    HTTP2_SESSION_RECV_RST_STREAM
                      --> error_code = "2 (INTERNAL_ERROR)"
                      --> stream_id = 1

Đối với những gì tôi đã đọc trong bài đăng khác này , " Trong HTTP / 2, nếu khách hàng muốn hủy bỏ yêu cầu, nó sẽ gửi RST_STREAM. Khi máy chủ nhận được RST_STREAM, nó sẽ ngừng gửi các khung DATA cho khách hàng, do đó dừng phản hồi (hoặc tải xuống). Kết nối vẫn có thể sử dụng được cho các yêu cầu khác và các yêu cầu / phản hồi đồng thời với yêu cầu đã bị hủy có thể tiếp tục tiến triển. [...] Có thể đến thời điểm RST_STREAM đi từ máy khách đến máy chủ, toàn bộ nội dung của yêu cầu đang được chuyển và sẽ đến máy khách, nó sẽ loại bỏ nó. Tuy nhiên, đối với nội dung phản hồi lớn, việc gửi RST_STREAM có thể có cơ hội đến máy chủ trước toàn bộ nội dung phản hồi được gửi và do đó sẽ tiết kiệm băng thông. "

Hành vi được mô tả giống như hành vi tôi có thể quan sát. Nhưng điều đó có nghĩa là trình duyệt là thủ phạm, và sau đó tôi sẽ không hiểu tại sao nó lại xảy ra trên hai trang giống hệt nhau với một trang có tiêu đề 200 và trang kia là 404 (tương tự nếu tôi tắt JS).

Trong vài tuần tôi cũng cảm thấy khó chịu vì "lỗi" này:

net :: ERR_HTTP2_PROTOCOL_ERROR 200

Trong trường hợp của tôi, nó đã xảy ra trên các hình ảnh được tạo bởi PHP.

Đó là ở header()cấp độ, và đặc biệt là về điều này:

header ('Content-Length:'. Filesize($cache_file));

Nó rõ ràng không trả lại kích thước chính xác, vì vậy tôi đã xóa nó và mọi thứ đều hoạt động tốt.

Vì vậy, Chrome kiểm tra tính chính xác của dữ liệu được truyền qua các tiêu đề và nếu không tương ứng, nó sẽ thất bại.

BIÊN TẬP

Tôi đã tìm thấy lý do tại sao content-lengththông qua filesizebị tính toán sai: quá trình GZIPnén được kích hoạt trên các tệp PHP, vì vậy loại trừ tệp đang đề cập sẽ khắc phục sự cố. Đặt mã này vào .htaccess:

SetEnvIfNoCase Request_URI ^ / thumb.php no-gzip -vary

Nó hoạt động và chúng tôi giữ tiêu đề Content-length.

Tôi không biết chính xác chuyện gì đang xảy ra, nhưng tôi đã tìm ra giải pháp.

Các tính năng CDN của OVH là thủ phạm. Tôi đã cài đặt nó trên dịch vụ máy chủ của mình nhưng bị vô hiệu hóa cho miền của tôi vì tôi không cần nó.

Bằng cách nào đó, khi tôi kích hoạt nó, mọi thứ đều hoạt động.

Tôi nghĩ rằng nó buộc Apache phải sử dụng giao thức HTTP2, nhưng điều tôi không hiểu là thực sự có một đề cập HTTP2 trong mỗi tiêu đề của tôi, mà tôi cho rằng máy chủ đã trả lời bằng cách sử dụng đúng giao thức.

Vì vậy, giải pháp cho trường hợp rất đặc biệt của tôi là kích hoạt tùy chọn CDN trên tất cả các miền liên quan.

Nếu bất cứ ai hiểu rõ hơn những gì có thể xảy ra ở đây, vui lòng chia sẻ giải thích.

Tôi gặp phải điều này vì máy chủ http2 đã đóng kết nối khi gửi phản hồi lớn tới Chrome.

Tại sao? Bởi vì nó chỉ là một cài đặt của máy chủ http2, được đặt tên là WriteTimeout .

Trong trường hợp của tôi, đó là - không còn chỗ trống trên máy chủ web.

Tôi đã gặp một vấn đề tương tự, tôi đã nhận được ERR_HTTP2_PROTOCOL_ERROR trên một trong những yêu cầu HTTP GET.

Tôi nhận thấy rằng bản cập nhật Chrome đang chờ xử lý, vì vậy tôi đã cập nhật trình duyệt Chrome lên phiên bản mới nhất và lỗi đã biến mất vào lần tới khi tôi khởi chạy lại trình duyệt.

Tôi gặp vấn đề này khi có một máy chủ Nginx phơi bày ứng dụng node-js ra thế giới bên ngoài. Nginx đã tạo tệp (css, js, ...) được nén bằng gzipvà với Chrome, nó trông giống như vậy.

Vấn đề được giải quyết khi chúng tôi thấy rằng máy chủ của nút-js cũng được nén nội dung bằng gzip. Trong một số trường hợp, nén đôi này dẫn đến vấn đề này. Hủy bỏ nén nút-js đã giải quyết vấn đề.

Lỗi này hiện đang được sửa: https://chromium-review.googlesource.com/c/chromium/src/+/2001234

Nhưng nó đã giúp tôi, thay đổi cài đặt nginx:

• bật gzip;
• add_header 'Kiểm soát bộ đệm' 'không lưu trữ, không có bộ đệm, phải xác nhận lại, proxy-xác nhận lại, max-age = 0';
• hết hạn;

Trong trường hợp của tôi, Nginx hoạt động như một proxy ngược cho ứng dụng Node.js.

Điều này xảy ra với tôi khi tôi đăng ký một tên miền mới, ví dụ: "new" cho example.com (new.example.com). Tên không thể được giải quyết tạm thời ở vị trí của tôi trong một vài giờ, trong khi nó có thể được giải quyết ở nước ngoài. Vì vậy, tôi đã sử dụng proxy để kiểm tra trang web nơi tôi thấynet::ERR_HTTP2_PROTOCOL_ERROR trong bảng điều khiển chrome cho một số bài đăng AJAX. Vài giờ sau, khi tên có thể được gửi lại cục bộ, những lỗi đó đã biến mất.

Tôi nghĩ lý do cho lỗi đó là các yêu cầu AJAX đó không được chuyển hướng bởi proxy của tôi, nó chỉ truy cập một trang web chưa được giải quyết bởi trình phân giải DNS cục bộ của tôi.

Tôi đã gặp phải lỗi này nhiều lần và, đó là do chuyển tài nguyên lớn (lớn hơn 3MB) từ máy chủ sang máy khách.

Tôi gặp vấn đề tương tự (asp, c # - HttpPostedFileBase) khi đăng một tệp lớn hơn 1MB (mặc dù ứng dụng không có bất kỳ giới hạn nào đối với kích thước tệp), đối với tôi, việc đơn giản hóa lớp mô hình đã giúp. Nếu bạn gặp phải vấn đề này, hãy thử loại bỏ một số phần của mô hình và xem liệu nó có giúp được gì không. Nghe có vẻ lạ, nhưng làm việc cho tôi.

Tôi đã gặp vấn đề này trong tuần qua vì tôi đã cố gắng gửi các yêu cầu XÓA đến máy chủ PHP của mình thông qua AJAX. Gần đây tôi đã nâng cấp gói lưu trữ của mình, nơi tôi có Chứng chỉ SSL trên máy chủ lưu trữ các tệp PHP và JS. Kể từ khi thêm Chứng chỉ SSL, tôi không còn gặp phải vấn đề này nữa. Hy vọng điều này sẽ giúp với lỗi lạ này.

Tôi cũng phải đối mặt với lỗi này và tôi tin rằng có thể có nhiều lý do đằng sau nó. Của tôi là, ARR đã hết thời gian.

Trong trường hợp của tôi, trình duyệt đã đưa ra yêu cầu đến một trang web proxy ngược nơi tôi đã đặt quy tắc chuyển hướng của mình và trang web proxy đó cuối cùng đang yêu cầu trang web thực tế. Bây giờ đối với dữ liệu khổng lồ, phải mất hơn 2 phút 5 giây và thời gian chờ yêu cầu ứng dụng cho máy chủ của tôi được đặt thành 2 phút. Tôi đã sửa lỗi này bằng cách tăng thời gian chờ ARR bằng các bước bên dưới: 1. Truy cập IIS 2. Nhấp vào tên máy chủ 3. Nhấp vào Ứng dụng yêu cầu định tuyến bộ đệm trong ngăn giữa 4. Nhấp vào Cài đặt proxy máy chủ trong khung bên phải 5. Tăng thời gian chờ 6 Nhấp vào Áp dụng

Trong trường hợp của chúng tôi, lý do là tiêu đề không hợp lệ. Như đã đề cập trong Chỉnh sửa 4:

• lấy nhật ký
• trong trình xem chọn Sự kiện
• đã chọn HTTP2_SESSION

Tìm kiếm một cái gì đó tương tự:

HTTP2_SESSION_RECV_INVALID_HEADER

-> error = "Ký tự không hợp lệ trong tên tiêu đề."

-> header_name = " charset = utf-8 "

Nhóm của tôi đã thấy điều này trên một tệp javascript duy nhất mà chúng tôi đang phục vụ. Mọi tập tin khác đều hoạt động tốt. Chúng tôi chuyển từ http2trở lại http1.1và sau đó net::ERR_INCOMPLETE_CHUNKED_ENCODINGhoặc ERR_CONTENT_LENGTH_MISMATCH. Cuối cùng, chúng tôi đã phát hiện ra rằng có một bộ lọc công ty (Trustwave) đã phát hiện nhầm "lỗi" (chúng tôi nghi ngờ nó đã phát hiện ra một cái gì đó trong tệp / tên tệp của chúng tôi giống với số an sinh xã hội). Bắt công ty tinh chỉnh bộ lọc này đã giải quyết các vấn đề của chúng tôi.

Chúng tôi gặp vấn đề này trên các trang có chuỗi Base64 dài. Sự cố xảy ra do chúng tôi sử dụng CloudFlare.

Chi tiết: https://community.cloudflare.com/t/err-http2-protatio-error/119619 .

Phần chính từ bài viết diễn đàn:

Sau khi thử nghiệm thêm trên các tab Ẩn danh trên nhiều trình duyệt, sau đó thực hiện các thay đổi về mã từ BASE64 thành hình ảnh .png thực, vấn đề không bao giờ xảy ra nữa, trong bất kỳ trình duyệt nào. .Png có khoảng 500kb trước khi trở thành một cơ sở64, vì vậy CloudFlare có vấn đề với các dòng văn bản khổng lồ trên cùng một dòng (vì base64 là một chuỗi dài) làm proxy giữa miền và heroku. Như đã đề cập trước đó, trực tiếp nhấn url Heroku cũng không bao giờ xảy ra sự cố.

Cách hack tạm thời là vô hiệu hóa HTTP / 2 trên CloudFlare.

Hy vọng ai đó khác có thể tạo ra một giải pháp tốt hơn mà không yêu cầu tắt HTTP / 2 trên CloudFlare.