Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Networking: fetch/XHR GETs can silently return stale cached responses — default HttpBaseProtocolFilter never sets CacheControl.ReadBehavior

Đang mở
  • Có gì không ổn?
#16,315 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
74/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
cpp, react-native
Lĩnh vực
api, networking

Hướng nghiên cứu

Bắt đầu trong vnext/Shared/Networking/RedirectHttpFilter.cpp, xem xét designated constructor, việc xây dựng bộ lọc mặc định của nó và passthrough của CacheControl(). Sau đó, theo dõi cách WinRTHttpResource.cpp xây dựng HttpClient và kiểm tra hành vi bằng các fetch/XHR GETs lặp lại đối với các response không có Cache-Control. Hoàn tất khi các GET mặc định không còn âm thầm trả về các response cũ trong cache và hành vi redirect hiện có vẫn được giữ nguyên.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Needs: Triage :mag:

Environment

  • react-native-windows 0.83.2 (also present on main as of 2026-07-17), new architecture (Fabric, composition), Win32/HWND host
  • Windows 11 (WinINet/WinHTTP cache active)
  • Reproduced in a production app against an authenticated JSON API

Steps to reproduce

  1. Have a backend endpoint that serves GET responses without a Cache-Control header (very common for JSON APIs — many frameworks send none by default).
  2. In a react-native-windows app, fetch() that endpoint (an Authorization header does not prevent the problem).
  3. Change the data server-side (e.g. save an edit through a POST/PUT), then fetch() the same GET URL again.

Expected

The second GET hits the network (or at least revalidates) and returns the updated data — matching the behavior of the same JS on React Native Android (OkHttp with no cache configured) and on browsers for heuristically-cacheable authenticated API responses.

Actual

The second GET returns the previous response body with an HTTP 200, with zero network I/O (confirmed: no request reaches the server). The OS HTTP cache (WinINet) answers the request using RFC 7234 heuristic caching, because nothing in the RNW networking stack opts out of cache reads. In our app this manifested as "saves silently revert": a screen re-fetched after a successful save and rendered the pre-save data.

Root cause

RedirectHttpFilter builds its inner filters as default-constructed HttpBaseProtocolFilters and only configures redirect/UI behavior — CacheControl().ReadBehavior is never set, so it stays at HttpCacheReadBehavior::Default, which permits serving cached entries without revalidation:

  • vnext/Shared/Networking/RedirectHttpFilter.cpp (current main):
    • Lines ~72–76: RedirectHttpFilter(winrt::hstring defaultUserAgent) delegates with winrt::Windows::Web::Http::Filters::HttpBaseProtocolFilter{} twice — default filters, default cache behavior.
    • Lines ~42–60: the designated constructor sets AllowAutoRedirect(false) and AllowUI(false) on both inner filters but never touches CacheControl().
  • Consumed by WinRTHttpResource (vnext/Shared/Networking/WinRTHttpResource.cpp), which builds the HttpClient used for all JS fetch/XHR traffic.

The class already implements CacheControl() passthrough (RedirectHttpFilter.cpp ~line 117), so the plumbing exists — nothing ever calls it.

Suggested fix

In the RedirectHttpFilter constructor (next to the AllowAutoRedirect(false) calls), set:

baseFilter.CacheControl().ReadBehavior(winrt::Windows::Web::Http::Filters::HttpCacheReadBehavior::NoCache);

on both inner filters, which aligns RNW with React Native Android (OkHttp is configured with no HTTP cache, so JS-visible fetch semantics match across platforms). If disabling cache reads by default is considered too aggressive, at minimum expose a configuration knob (e.g. via IHttpModuleProxy/HttpSettings or a ReactPropertyBag property) so apps can opt out of WinINet cache reads — today there is no way to do this from app code short of cache-busting every URL.

Workaround (what we ship today)

  • Server: middleware adding Cache-Control: no-store on all API GET responses.
  • Client (Windows only): axios/fetch interceptor appending a _ts=<Date.now()> query parameter to every GET to defeat the WinINet cache key.

Both are required for apps that cannot control every backend; neither should be necessary.

Ngôn ngữ chính
C++
Star
17.4k
Fork
1.2k
Merge trung bình
2 ngày 23 giờ
Pull request đã merge (30 ngày)
16

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/react-native-windows

Tất cả issue của microsoft/react-native-windows

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.