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

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)

Đang mở
  • Có gì không ổn?
#4,028 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 1 ngày

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

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
8/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
html, javascript, typescript
Lĩnh vực
frontend, security

Hướng nghiên cứu

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.

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

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
36.1k
Fork
1.1k
Merge trung bình
11 giờ 49 phút
Pull request đã merge (30 ngày)
346

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

Tất cả issue của solidjs/solid

Issue tương tự

Thêm issue về TypeScript

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.