Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue 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)

Aperta
#4,028 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
8/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
html, javascript, typescript
Ambito
frontend, security

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
36.1k
Fork
1.1k
Merge medio
11h 32m
PR unite (30g)
356

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di solidjs/solid

Tutte le issue di solidjs/solid

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.