Page caching: document the warm origin, and that rendering and warming need different URLs
まだ誰も着手していません。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 75/100
- issue の種類
- ドキュメント
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- docker, javascript, kubernetes, node.js, nuxtjs
- 領域
- backend, devops, documentation
調査の方向性
編集するファイルは content/5.nuxt-module/11.page-caching.md で、具体的には「Warming the cache from site settings」セクションです。既存のドキュメントを読んで現在の構造を理解し、NUXT_CWA_PAGE_CACHE_WARM_ORIGIN を設定するタイミングと理由について、シングルサーバーと Kubernetes デプロイメントに焦点を当てた説明を追加してください。Issue で言及されている Caddy 証明書のパスを、プロジェクトのボリュームレイアウトに対して確認します。single-flight ロックと失敗リストに関する2つの小さな修正も組み込まれていることを確認してください。ドキュメントをローカルでビルドして、書式が保持されていることを確認するテストを行います。
索引モデルが issue の本文から書いたものです。
説明
From cwa-nuxt-module#343. The module change is diagnosis only — how the warm connects is unchanged — but the page-caching docs are missing the thing that makes a single-server deploy work at all.
Page: content/5.nuxt-module/11.page-caching.md, in Warming the cache from site settings. NUXT_CWA_PAGE_CACHE_WARM_ORIGIN is listed as an option, but not when you would set it — and on a single-server deploy it is mandatory, not an escape hatch.
The point to get across
origin defaults to the origin of apiUrl, and the public host still travels in the Host header, so the page is stored under the key visitors hit and the request never leaves the cluster.
On Kubernetes, leave it unset — Caddy there listens on port 80 with no HTTPS and no redirect, so the derived origin is already right.
On a single-server deploy, where Caddy runs its own automatic HTTPS, it must be set, and to a different URL from the one the server renders with. These are not the same request and they need different schemes:
| URL | Why | |
|---|---|---|
Rendering (apiUrl) |
http://php.local/_api |
Over HTTPS the TLS name would be the internal host, which only an internally issued certificate covers, and Node rightly refuses it. |
Warming (NUXT_CWA_PAGE_CACHE_WARM_ORIGIN) |
https://php.local |
The warm sends the public Host, so the TLS name becomes the real domain and its ACME certificate validates. |
Over plain HTTP on that stack, Caddy's automatic HTTPS answers every page with a 308, so every page is reported failed and nothing is warmed.
Worth stating explicitly: don't keep the warm on HTTP to dodge the certificate. Caddy's reverse_proxy sets X-Forwarded-Proto from the scheme it terminated, so pages would be rendered and cached with http:// canonical and og:url values no visitor ever receives — for the API's full cache lifetime.
Where Caddy issues the certificate itself (SERVER_NAME=localhost, a .local host, or tls internal) the warm fails with DEPTH_ZERO_SELF_SIGNED_CERT, because Node does not trust Caddy's own root. Point Node at it with NODE_EXTRA_CA_CERTS (Caddy writes the root to /data/caddy/pki/authorities/local/root.crt in its data volume) or --use-system-ca once it is installed in the system trust store. Local development hits the same wall against the self-signed certificate; set origin to a plain http:// URL there instead.
The module offers no way to turn certificate verification off, and won't — worth saying in the docs so nobody goes looking. It would be a permanent invisible downgrade in the only TLS client the module has, and it would make a misconfigured origin succeed quietly: pointed at the wrong host you would be told every page was warmed while nothing was stored.
Two smaller corrections on the same page
- The single-flight lock is per process: a second request to the same server gets a
409while one is running, but separate replicas can warm at the same time. The admin message now says "on this server". - The failure list now names the cause: a redirect shows where it was sent —
/about (308 → https://www.example.com/about)— and an unreachable page shows the underlying error code —/about (no response: DEPTH_ZERO_SELF_SIGNED_CERT). Only a200counts as warmed; the page list already excludes redirect routes, so a3xxhere means the request never reached the renderer.
One thing to check before publishing
The /data/caddy/pki/authorities/local/root.crt path is Caddy's documented default but was not confirmed against the template's volume layout — worth a glance.
Background on why the obvious fix was rejected: the issue originally proposed setting servername for https origins. That is a no-op — Node's HTTP agent derives the TLS server name and the certificate identity check from the Host header when none is set, verified against a real TLS server with an SNICallback. The only real failure is certificate trust, which no module code can fix.
- 主要言語
- TypeScript
- スター
- 0
- フォーク
- 0
- 平均マージ
- 1時間 20分
- マージ済み PR（30日）
- 1
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
components-web-app/docs のほかの issue
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
components-web-app/docs#260 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
components-web-app/docs#259 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
components-web-app/docs#258 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
components-web-app/docs#257 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
components-web-app/docs#256 · コメント 1 件 ·
components-web-app/docs の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
ccch1mneyyy/dsh-TUI#1631 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
MiniMax-AI/minimax-code#507 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
Transient OAuth login failure persists in getLoginStatus and masks active account in dashboard再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンaccount-pool bug gui
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
lidge-jun/opencodex#7378 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信