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

SSR + strict CSP for cached pages: let hydration data be inert so inline-script hashes are build-time constants (and streaming works under a hash-based CSP)

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

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
8/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
html, javascript, typescript
Área
frontend, security

Línea de trabajo

This is a design proposal with no maintainer response yet, so decide scope with maintainers before coding. Start by reading the inline-script constants (REPLACE_SCRIPT, HEAD_SCRIPT, HydrationScript) and the renderToStream / renderToString entry points the issue names. Done means a failing test that shows which inline scripts change between renders, as the issue's first deliverable.

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

Descripción

Problem. We run a Solid 2 storefront (rc.13, @solidjs/vite-plugin start mode) behind a
shared CDN cache, with a CSP that has no 'unsafe-inline'. Three facts collide:

  1. A nonce is unusable on a cached page. The stored response publishes its CSP header and its
    <script nonce> attributes together, to every later visitor, for the whole cache lifetime. The
    published constant becomes the grant. SvelteKit forbids nonces on prerendered pages for the
    same reason, and Next.js documents that nonces force dynamic rendering and disable static, ISR
    and CDN caching.
  2. Hashes are the remaining mechanism, but Solid's inline scripts cannot be hashed ahead of
    time.
    • Every script that carries hydration data is per render: the seroval cross-reference header,
      the stub batch, the resolutions, $df("k"), head ops, window.location=.
    • The constant runtimes (REPLACE_SCRIPT, HEAD_SCRIPT, seroval's promise-resolver factory)
      are concatenated into the same element as that data.
    • Only HydrationScript is a standalone constant.
      So a host must render, re-read the finished body, and hash the scripts. That only works with
      the async render mode, where the head is sent after the body.
  3. Streaming is impossible under a hash-based CSP. The header is gone before the late scripts
    exist.

A side effect we measured: in async mode, the order of the resolution chunks (and their $R ids)
follows the order in which async sources settle. Identical data with different API latency gives
different bytes (12 renders, 2 variants), so a body-digest ETag misses revalidations that should
be 304s.

Proposals, ranked.

  1. Inert hydration data plus constant executable code (opt-in, for example
    renderToStream(…, { dataMode: 'json' })):
    • Write every serialized record as <script type="application/json" data-hy> using the JSON
      codec @solidjs/web/serialization already ships (createJSONSerializer /
      createJSONDataTable).
    • Keep all executable bytes constant per build: the runtime in its own <script>, or an
      external module, and a fixed pump such as <script>_$HY.p()</script> after each flush.
    • Make the late redirect a <meta http-equiv="refresh"> or a data record.
    • Two details to handle: the decoder must stamp p.s / p.v on settled promises, as
      PROMISE_SUCCESS does today, since hydration reads them synchronously; and seroval's
      cross-JSON already resolves out-of-order promise nodes by id.
      Result: CSP hashes are build-time constants (a static header, no body re-parse), and streaming
      SSR works under a strict, hash-only CSP      . The cost from our measurement is about 5% larger
      payloads after compression and slower decode (0.7 vs 0.1 ms for a 120-product payload on a
      laptop).
  2. Interim, small: the renderer records the SHA-256 of every inline script it writes and
    exposes the set on the settled result (or the request event), for hosts that render in async
    mode or with renderToString. Authored <script> in JSX stays the app's job, since the
    compiler bakes it into the template.
  3. Determinism: in async mode, emit resolutions in a stable order (for example, by
    serialization key at flush) rather than in settle order, so identical data gives identical
    bytes.

Prior art.

  • SvelteKit: csp.mode: 'hash' | 'nonce' | 'auto'. The framework adds hashes or nonces for
    the inline scripts and styles it generates. auto uses hashes for prerendered pages and nonces
    for dynamic ones, and "using nonces with prerendered pages is insecure and therefore forbidden".
  • Astro 6: security.csp computes SHA-256 hashes of the page's scripts and styles and emits
    them in a <meta http-equiv> policy.
  • Next.js: nonces only for inline scripts, which require dynamic rendering. Experimental SRI
    covers external files only.
  • React Router / Remix and Qwik: nonce props only.
  • SolidStart v2 already moved server-function payloads to seroval's JSON mode by default
    (solid-start#2042, after #1825).

What we would contribute.

  • A failing test for each claim above: the per-render inventory, and the settle-order variance.
  • A prototype of (1) behind an option: the serializer switch, the pump and the decoder wrapper
    that stamps s / v.
  • Size and decode benchmarks on a real catalogue page.
  • The docs section on running Solid behind a shared cache with a strict CSP.

We are happy to start with (2) or (3) if (1) is too large for 2.0.

Lenguaje dominante
TypeScript
Estrellas
36.1k
Forks
1.1k
Merge medio
11 h 49 min
PR fusionados (30 d)
346

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 solidjs/solid

Todos los issues de solidjs/solid

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.