Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#16,315 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
74/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
cpp, react-native
Área
api, networking

Línea de trabajo

Comienza en vnext/Shared/Networking/RedirectHttpFilter.cpp, revisando el designated constructor, la construcción de su filtro predeterminado y el passthrough de CacheControl(). Después, sigue cómo WinRTHttpResource.cpp construye el HttpClient y verifica el comportamiento con fetch/XHR GETs repetidos contra respuestas sin Cache-Control. La tarea estará completa cuando los GETs predeterminados dejen de servir silenciosamente respuestas obsoletas almacenadas en caché y el comportamiento existente de redirección siga intacto.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C++
Estrellas
17.4k
Forks
1.2k
Merge medio
3 d 10 min
PR fusionados (30 d)
14

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/react-native-windows

Todos los issues de microsoft/react-native-windows

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.