CẨN THẬN CẨN THẬN: tiêu đề tạm thời được hiển thị trong chương trình gỡ lỗi Chrome

Tôi nhận thấy một thông báo thận trọng kỳ lạ khi xem các tài nguyên đã tải xuống bằng Google chrome Inspector ( F12):

Tiêu đề tạm thời thận trọng được hiển thị

Tôi đã tìm thấy một cái gì đó có thể có liên quan, Bảng điều khiển mạng: thận trọng hơn về các tiêu đề yêu cầu tạm thời , nhưng tôi không thể hiểu đầy đủ về nó. Các câu hỏi liên quan có thể được tìm thấy yêu cầu khối Chrome cũng như XMLHttpRequest không thể tải. Tài nguyên không tải cho thấy sự thận trọng: Các tiêu đề tạm thời được hiển thị .

Tương tự như câu hỏi đầu tiên , tài nguyên của tôi đã bị chặn, nhưng sau đó tự động tải cùng một tài nguyên. Không giống như câu hỏi thứ hai , tôi không muốn sửa bất cứ điều gì; Tôi muốn biết tin nhắn này có nghĩa là gì và tại sao tôi nhận được nó.

Tài nguyên có thể bị chặn bởi một tiện ích mở rộng (AdBlock trong trường hợp của tôi).

Thông báo có ở đó bởi vì yêu cầu truy xuất tài nguyên đó không bao giờ được thực hiện, vì vậy các tiêu đề được hiển thị không phải là thực tế. Như đã giải thích trong vấn đề bạn đã tham chiếu, các tiêu đề thực được cập nhật khi máy chủ phản hồi, nhưng không có phản hồi nếu yêu cầu bị chặn.

Cách tôi tìm thấy về tiện ích mở rộng đang chặn tài nguyên của mình là thông qua công cụ mạng nội bộ trong Chrome:

Đối với phiên bản mới nhất của chrome

• Nhập chrome://net-export/vào thanh địa chỉ và nhấn enter.
• Bắt đầu thu. Và lưu tập tin ghi âm vào địa phương.
• Mở trang đang hiển thị vấn đề.
• Quay trở lại mạng nội bộ
• Bạn có thể xem tệp Nhật ký đã ghi tại đây https://netlog-viewer.appspot.com/#import
• nhấp vào các sự kiện (###) và sử dụng trường văn bản để tìm sự kiện liên quan đến tài nguyên của bạn (sử dụng các phần của URL).
• Cuối cùng, nhấp vào sự kiện và xem nếu thông tin hiển thị cho bạn biết điều gì đó.

Đối với các phiên bản cũ hơn của chrome

• Nhập chrome://net-internalsvào thanh địa chỉ và nhấn enter.
• Mở trang đang hiển thị vấn đề.
• Quay trở lại mạng nội bộ, nhấp vào các sự kiện (###) và sử dụng trường văn bản để tìm sự kiện liên quan đến tài nguyên của bạn (sử dụng các phần của URL).
• Cuối cùng, nhấp vào sự kiện và xem nếu thông tin hiển thị cho bạn biết điều gì đó.

Tôi tin rằng nó xảy ra khi yêu cầu thực tế không được gửi. Thường xảy ra khi bạn đang tải một tài nguyên được lưu trữ.

Đối với chrome v72 + điều đã giải quyết nó cho tôi chỉ là thế này:

đi đến chrome://flags/và vô hiệu hóa 3 lá cờ này

• Vô hiệu hóa cách ly trang web
• Cho phép dịch vụ mạng
• Chạy dịch vụ mạng đang xử lý

hoặc bạn có thể làm điều đó từ dòng lệnh:

chrome --disable-site-isolation-trials --disable-features=NetworkService,NetworkServiceInProcess

tại sao điều này xảy ra

Có vẻ như Google đang tái cấu trúc công cụ Chromium của họ thành cấu trúc mô đun, trong đó các dịch vụ khác nhau sẽ được tách thành các mô-đun và quy trình độc lập. Họ gọi quy trình này là dịch vụ. Dịch vụ mạng là bước đầu tiên, dịch vụ Ui, dịch vụ nhận dạng và dịch vụ thiết bị sắp ra mắt. Google cung cấp thông tin chính thức tại trang web của dự án Chromium .

Thay đổi điều đó có nguy hiểm không?

Một ví dụ là kết nối mạng: một khi chúng ta có một dịch vụ mạng, chúng ta có thể chọn chạy nó ra khỏi quy trình để có sự ổn định / bảo mật tốt hơn hoặc trong quá trình nếu chúng ta bị hạn chế tài nguyên . nguồn

Tôi đã gặp phải vấn đề này và tôi đã cố gắng xác định một nguyên nhân cụ thể, không được đề cập ở trên trong câu trả lời hoặc câu hỏi.

Tôi đang chạy một ngăn xếp js đầy đủ, mặt trước góc cạnh và mặt sau nút trên SSL và API nằm trên một miền khác chạy trên cổng 8081, vì vậy tôi đang thực hiện các yêu cầu CORS và withCredentials khi tôi thả cookie phiên từ API

Vì vậy, cụ thể kịch bản của tôi là: POST request, withCredentials đến cổng 8081 gây ra thông báo "THẬN TRỌNG: tiêu đề tạm thời được hiển thị" trong thanh tra và tất nhiên cũng chặn tất cả yêu cầu cùng nhau.

Giải pháp của tôi là thiết lập apache để proxy chuyển yêu cầu từ cổng SSL thông thường 443 sang cổng SSL của nút 8081 (nút phải ở cổng cao hơn vì không thể chạy dưới quyền root trong prod). Vì vậy, tôi đoán Chrome không thích các yêu cầu SSL đối với các cổng SSL độc đáo, nhưng có lẽ thông báo lỗi của chúng có thể cụ thể hơn.

Điều này cũng có thể xảy ra (chỉ dành cho các yêu cầu có nguồn gốc chéo) vì một tính năng mới gọi là cách ly trang web

Trang này nêu chi tiết vấn đề và cách giải quyết . Đó là chuyển sang chrome://flags/#site-isolation-trial-opt-outchrome và thay đổi cài đặt đó thành "Chọn không tham gia" và tải lại chrome.

Đó là một vấn đề được biết đến . Tuy nhiên, trang đó cho biết nó đã được sửa trong chrome 68, nhưng tôi đang chạy chrome 68 và tôi vẫn gặp sự cố.

HTTP / 2 Tài nguyên được đẩy sẽ tạo ra Provisional headers are showntrong trình kiểm tra cho cùng một lý thuyết như @wvega đã đăng trong câu trả lời của anh ta ở trên .

ví dụ: Vì máy chủ đã đẩy (các) tài nguyên đến máy khách ( trước khi máy khách yêu cầu chúng ), trình duyệt có các tài nguyên được lưu trong bộ nhớ cache và do đó máy khách không bao giờ thực hiện / cần một yêu cầu; Vì vậy ...

... các tiêu đề thực được cập nhật khi máy chủ phản hồi, nhưng không có phản hồi nếu yêu cầu bị chặn.

Tình hình của tôi là liên quan đến nguồn gốc .
Tình huống: Trình duyệt gửi OPTIONSyêu cầu trước khi gửi yêu cầu thực sự như GEThoặc POST. Nhà phát triển cuối cùng quên xử lý OPTIONSyêu cầu, để nó đi qua mã dịch vụ, khiến thời gian xử lý quá lâu. Dài hơn cài đặt thời gian chờ tôi đã viết trong phần axioskhởi tạo, là 5000 mili giây. Do đó, yêu cầu thực sự không thể được gửi, và sau đó tôi gặp phải provisional headers are shownvấn đề.
Giải pháp: Khi có OPTIONSyêu cầu, api phụ trợ chỉ trả về kết quả, nó làm cho yêu cầu nhanh hơn và yêu cầu thực sự có thể được gửi trước khi hết thời gian.

Tôi nghi ngờ câu trả lời của tôi là kịp thời để giúp bạn nhưng những người khác có thể thấy nó hữu ích. Tôi đã gặp một vấn đề tương tự với tập lệnh jQuery Ajax Post mà tôi đã tạo.

Hóa ra tôi có một lỗi đánh máy trong thuộc tính href của thẻ A mà tôi đang sử dụng để kích hoạt bài viết. Tôi đã gõ href = " javacsript :;" (đảo ngược 's' và 'c') .. điều này khiến tập lệnh cố gắng làm mới trang trong khi bài đăng đang cố gắng kích hoạt. Sửa lỗi đánh máy và nó hoạt động hoàn toàn tốt đối với tôi.

Thông báo này có thể xảy ra khi trang web được bảo vệ bằng HSTS . Sau đó, khi ai đó liên kết với phiên bản HTTP của URL, trình duyệt, theo hướng dẫn của HSTS, không đưa ra yêu cầu HTTP, nhưng chuyển hướng nội bộ đến tài nguyên HTTPS một cách an toàn. Điều này là để tránh các cuộc tấn công hạ cấp HTTPS như sslstrip .

Điều đó có thể là do bạn đã gửi một yêu cầu Ajax, đồng thời bạn chuyển trang của mình sang một trang khác bằng location.href hoặc đại loại như thế. Vì vậy, yêu cầu trước đó không thành công.

Thông báo thận trọng này cũng xảy ra nếu phản hồi không hợp lệ và do trình duyệt bỏ.

Trong trường hợp của tôi, yêu cầu được gửi chính xác đến máy chủ, mã phía máy chủ sau đó tạo ra lỗi và việc xử lý lỗi tùy chỉnh của tôi đã trả về thông báo lỗi trong trường thông báo trạng thái HTTP. Nhưng lỗi này không được nhận ở phía máy khách, do các ký tự không hợp lệ trong thông báo lỗi (được mô tả tại đây http://aspnetwebstack.codeplex.com/workitem/1386 ) dẫn đến tiêu đề phản hồi bị hỏng.

Tôi gặp vấn đề này với một cuộc gọi AJAX sẽ không bao giờ hoàn thành. Tôi đã làm theo lời khuyên và mẹo của wvega về việc gỡ lỗi chrome://net-internalsđể cuối cùng xác định một clicktrình xử lý sự kiện khác trong trang, nghe trên nút cha, khiến trình duyệt điều hướng đến cùng một URL (vì vậy nó không dễ nhận thấy).

Giải pháp là thêm event.stopPropagation()một clicktrình xử lý vào nút gửi biểu mẫu để giữ cho nhấp chuột không làm hỏng DOM và hủy yêu cầu AJAX đang diễn ra (được bắt đầu thông qua một submittrình xử lý trên form).

Gần đây tôi đã có điều này xuất hiện (thực tế là ngày hôm nay) khi tôi có một cuộc gọi AJAX đến máy chủ và Chrome kích hoạt "Chú ý: Tiêu đề tạm thời được hiển thị." Trong kịch bản PHP phía máy chủ, có các truy vấn MySQL có thể diễn ra khá nhanh hoặc mất vài giây tùy thuộc vào kịch bản đã cho. Phản hồi máy chủ của tôi không được gửi trở lại trình duyệt cho đến khi các truy vấn được hoàn thành. Tôi đã tìm thấy tôi chỉ gặp lỗi này khi các truy vấn tốn thời gian (tổng cộng tối đa vài giây) đang được thực hiện và ngăn phản hồi được gửi lại.

Kịch bản của tôi liên quan đến khả năng rất hiếm khi phải thay đổi bảng bằng cách thêm / xóa hàng trăm cột cho đầu ra mô hình thời tiết ... do đó độ trễ phản hồi từ việc lặp qua một vòng truy vấn ALTER TABLE.

Một lý do phổ biến điều này xảy ra là nếu bạn đang theo dõi một sự kiện và bạn không ngăn chặn hành động mặc định. Ví dụ: nếu bạn có một sự kiện nhấp chuột, thì bạn sẽ muốn bao gồm:

e.preventDefault();

hoặc là

return false;

Nếu bạn không, bạn sẽ thấy cảnh báo tiêu đề tạm thời cũng như trạng thái "bị hủy" trong tab Mạng của bảng điều khiển web của bạn.

Trong trường hợp của tôi, đó chỉ là một đường dẫn được đặt sai vào tài nguyên (svg / img)

Sự cố này xảy ra với tôi khi tôi đang gửi tiêu đề Ủy quyền HTTP không hợp lệ. Tôi quên để mã hóa base64 nó.

Tôi đã bắt gặp điều này và nó đã biến mất khi tôi chuyển từ https sang http. Các chứng chỉ SSL mà chúng tôi sử dụng trong nhà phát triển không được xác minh bởi bên thứ 3. Họ chỉ là những nhà phát triển địa phương.

Các cuộc gọi tương tự chỉ hoạt động tốt trong Chrome Canary và Firefox. Các trình duyệt này dường như không nghiêm ngặt về chứng chỉ SSL như Chrome. Các cuộc gọi sẽ thất bại trong Chrome với thông báo "THẬN TRỌNG: Tiêu đề tạm thời ...".

Tôi nghĩ / hy vọng rằng khi chúng tôi sử dụng chứng chỉ SSL hợp pháp trong giai đoạn và sản phẩm, chúng tôi sẽ không thấy hành vi này trong Chrome nữa.

Chỉ cần ném vào hai xu của tôi. Tôi đang viết Ứng dụng web bằng các yêu cầu CORS và dịch vụ web RESTful đầy đủ. Tôi đã tìm thấy chrome sẽ ném lỗi này khi tôi có một ngoại lệ chưa được xử lý hoặc lỗi PHP bị ném. Chỉ cần kích động bất cứ ai khác chạy vào vấn đề. Tôi thấy rằng khi điều này xảy ra, tôi có thể kích hoạt Ứng dụng Chrome "Người đưa thư - Khách hàng nghỉ ngơi" và chạy cùng một yêu cầu chính xác nhưng trong Ứng dụng Chrome tôi thực sự sẽ gặp phải Lỗi PHP bị ném thay vì lỗi không mô tả này.

Tôi đã chạy vấn đề này khi tôi cố tải main.js để yêu cầu js lần thứ hai sau khi tôi thực hiện các thay đổi do lỗi. Tôi vừa bật trong Cài đặt công cụ dành cho nhà phát triển "Tắt bộ nhớ cache (Khi DevTools đang mở)". và điều đó đã làm nên sự quyến rũ.

Một kịch bản có thể khác mà tôi đã thấy - yêu cầu chính xác tương tự đang được gửi lại chỉ sau vài mili giây (rất có thể là do lỗi ở phía máy khách).
Trong trường hợp đó, bạn cũng sẽ thấy rằng trạng thái của yêu cầu đầu tiên là "bị hủy" và độ trễ chỉ là vài mili giây.

Điều này đã xảy ra với tôi, khi tôi có một liên kết tải xuống và sau khi nhấp vào nó, tôi cũng đã cố gắng để bắt được nhấp với jquery và gửi yêu cầu ajax. Vấn đề là bởi vì khi bạn nhấp vào liên kết tải xuống, bạn sẽ rời khỏi trang, thậm chí nó không giống như vậy. Nếu không có chuyển tập tin, bạn sẽ thấy trang được yêu cầu .. Vì vậy, tôi đặt mục tiêu = "_ blank" để ngăn chặn sự cố này.

Tôi đã gặp lỗi này khi tôi cố in một trang trong cửa sổ bật lên. Hộp thoại in đã được hiển thị và nó vẫn đang chờ tôi chấp nhận hoặc hủy in trong cửa sổ bật lên trong khi ở trang chính cũng đang chờ trong nền hiển thị thông báo tiêu đề tạm thời THẬN TRỌNG được hiển thị khi tôi cố gắng nhấp vào liên kết khác.

Trong trường hợp của tôi, giải pháp là loại bỏ window.print ();tập lệnh mà nó đang thực thi trên <body>cửa sổ bật lên để ngăn hộp thoại in.

Tôi đã thấy điều này xảy ra khi số lượng kết nối đến máy chủ của tôi vượt quá giới hạn tối đa 6 kết nối trên mỗi máy chủ của Chrome.

Sử dụng mã này nắm tay mã của bạn:

header('Cache-Control: no-cache, no-store, must-revalidate');
header('Pragma: no-cache');
header('Expires: 0');

Điều này làm việc cho tôi.

Đây là một giải pháp khác.

Nếu bạn gặp phải vấn đề này với cuộc gọi $ ajax (), hãy thêm http://trước khi serverhost của bạn giải quyết vấn đề của bạn.

var requestURL = "http://" + serverHost;
$.ajax({
    dataType: "json",
    url: requestURL,
    data: data,
    success: success    
});

Nếu bạn đang phát triển ứng dụng Asp.Net Mvc và bạn đang cố gắng trả lại một JsonResulttrong bộ điều khiển của mình, hãy đảm bảo bạn thêm JsonRequestBehavior.AllowGetvào Jsonphương thức. Điều đó đã sửa nó cho tôi.

public JsonResult GetTaskSubCategories(int id)
{
    var subcategs = FindSubCategories(id);

    return Json(subcategs, JsonRequestBehavior.AllowGet);  //<-- Notice it has two parameters
}

Thông báo "Chú ý: tiêu đề tạm thời được hiển thị" có thể được hiển thị khi trang web được lưu trữ trên HTTPS gọi các cuộc gọi đến WebApi được lưu trữ trên HTTP. Bạn có thể kiểm tra tất cả nếu tất cả Api của bạn là HTTPS. Trình duyệt ngăn chặn để thực hiện một cuộc gọi đến tài nguyên không an toàn. Bạn có thể thấy thông báo tương tự trong mã của mình khi sử dụng API FETCH cho miền với HTTP.

Nội dung hỗn hợp: Trang tại ' https://website.com ' đã được tải qua HTTPS, nhưng yêu cầu tài nguyên không an toàn ' http://webapi.com '. Yêu cầu này đã bị chặn; nội dung phải được phục vụ qua HTTPS.

Tôi đã có một vấn đề tương tự với ứng dụng MEAN của tôi. Trong trường hợp của tôi, vấn đề đã xảy ra chỉ trong một yêu cầu. Tôi đã thử xóa quảng cáo, thử xóa bộ nhớ cache và thử với các trình duyệt khác nhau. Không có gì giúp được.

cuối cùng, tôi đã nhận ra rằng api đang cố gắng trả lại một đối tượng JSON lớn. Khi tôi đã cố gắng gửi một đối tượng nhỏ, nó đã hoạt động tốt. Cuối cùng, tôi đã thay đổi cách triển khai của mình để trả về bộ đệm thay vì JSON.

Tôi muốn expressJS ném lỗi trong trường hợp này.

Vấn đề này cũng sẽ xảy ra trong khi sử dụng một số gói như webpack-hot-middlewarevà mở nhiều trang cùng một lúc. webpack-hot-middlewaresẽ tạo một kết nối cho mỗi trang để lắng nghe những thay đổi của mã sau đó để làm mới trang. Mỗi trình duyệt có mộtmax-connections-per-server giới hạn là 6 cho Chrome, vì vậy nếu bạn đã mở hơn 6 trang trong Chrome, yêu cầu mới sẽ được treo ở đó cho đến khi bạn đóng một số trang.

Trong trường hợp của tôi, nguyên nhân là phần mở rộng AdBlock.

Yêu cầu đến máy chủ đã được thực hiện và tôi đã nhận được phản hồi nhưng tôi không thể thấy cookie yêu cầu do "Tiêu đề tạm thời .." được hiển thị trong các công cụ Dev. Sau khi vô hiệu hóa AdBlock cho trang web, cảnh báo biến mất và các công cụ dev bắt đầu hiển thị lại cookie.

Để thay đổi có hiệu lực, cũng cần phải đóng các công cụ Dev và làm mới trang