useRequestHeaders
useRequestHeaders を使用して、受信リクエストヘッダーにアクセスします。
組み込みの useRequestHeaders コンポーザブルを使用して、ページ、コンポーネント、およびプラグイン内で受信リクエストヘッダーにアクセスできます。
// すべてのリクエストヘッダーを取得
const headers = useRequestHeaders()
// cookie リクエストヘッダーのみを取得
const headers = useRequestHeaders(['cookie'])
ブラウザでは、useRequestHeaders は空のオブジェクトを返します。
例
useRequestHeaders を使用して、SSR 中に初期リクエストの authorization ヘッダーを任意の将来の内部リクエストにプロキシすることができます。
以下の例では、authorization リクエストヘッダーをアイソモーフィックな $fetch 呼び出しに追加しています。
tips
このセクションは公式ドキュメントの翻訳ではなく、本サイト独自の補足記事です。
NuxtのuseRequestHeadersとは?〜リクエストヘッダーを自在に扱うために〜
Nuxtアプリケーションを開発する際、サーバーサイドレンダリング(SSR)環境でクライアントから送られてくるHTTPリクエストのヘッダー情報を取得したい場面は多々あります。例えば、認証トークンを含むauthorizationヘッダーをAPIリクエストに引き継いだり、ユーザーの言語設定を判別して多言語対応を行ったりするケースです。
useRequestHeadersは、こうしたリクエストヘッダーを簡単に取得できるNuxtの組み込みコンポーザブルです。これを使うことで、SSR中の初期リクエストヘッダーを安全にアクセスし、必要に応じて内部API呼び出しなどに活用できます。
本記事では、useRequestHeadersの基本的な使い方から、実務での具体的なユースケース、注意すべきポイントまでを丁寧に解説します。Nuxt初心者から中級者の方が、より安全かつ効率的にヘッダー情報を扱えるようになることを目指しています。
まず結論:useRequestHeadersのポイントまとめ
- SSR環境で受信したHTTPリクエストヘッダーを取得できる
- 引数にヘッダー名の配列を渡すと、指定したヘッダーのみ取得可能
- クライアントサイドでは空のオブジェクトを返すため、SSR限定の機能
- 認証情報やカスタムヘッダーをAPI呼び出しに引き継ぐのに便利
- 適切に使わないとセキュリティリスクやパフォーマンス低下の原因になる
いつ使うべき?使わない方がよいケースは?
使うべきケース
-
SSR中に初期リクエストのヘッダー情報を利用したいとき
例:認証トークンをAPIリクエストに渡す、ユーザーの言語設定を判別するなど。 -
サーバー間通信でクライアントのヘッダーを引き継ぎたいとき
例えば、Nuxtサーバーから別のバックエンドAPIへリクエストを送る際に、元のリクエストのヘッダーをそのまま渡す場合。 -
プラグインやミドルウェアでリクエストヘッダーを参照したいとき
使わない方がよいケース
-
クライアントサイドでのヘッダー取得
クライアントでは常に空のオブジェクトが返るため、クライアント専用の処理には向かない。 -
ユーザー入力や外部からの信頼できないヘッダーをそのまま利用する場合
セキュリティ上のリスクがあるため、ヘッダーの検証やサニタイズが必要。 -
大量のヘッダーを無差別に取得してパフォーマンスに影響を与える場合
必要なヘッダーだけを指定して取得することが推奨される。
実務でよくあるユースケースとサンプルコード
1. 認証トークンをAPIリクエストに引き継ぐ
SSR中に受け取ったauthorizationヘッダーを、内部API呼び出しに渡す例です。
const { data, error } = await useFetch('/api/user/profile', {
headers: useRequestHeaders(['authorization'])
})
このようにすることで、ユーザーの認証情報を安全にAPIに伝搬できます。
2. 多言語対応のためのaccept-languageヘッダー取得
ユーザーのブラウザ設定に基づき、言語を判別して初期表示を切り替えたい場合。
const headers = useRequestHeaders(['accept-language'])
const userLang = headers['accept-language']?.split(',')[0] || 'en'
この値をもとに、Nuxtのi18n設定やコンテンツの切り替えに活用できます。
3. カスタムヘッダーを使ったAPI認証やトラッキング
例えば、x-client-idのような独自ヘッダーを取得してログに残したり、APIに渡したりするケース。
const headers = useRequestHeaders(['x-client-id'])
console.log('Client ID:', headers['x-client-id'])
よくある落とし穴・注意点
SSRとCSRの違いに注意
useRequestHeadersはSSR時にのみ有効で、クライアントサイドでは空のオブジェクトを返します。
そのため、クライアント側でヘッダー情報を期待すると動作しません。クライアントで必要な情報は別途取得方法を検討してください。
Hydration時の不整合に注意
SSRで取得したヘッダー情報をもとに描画した内容と、クライアント側の状態が異なるとHydrationエラーが発生することがあります。
ヘッダーに依存する表示はSSRとCSRで差異が出ないように設計しましょう。
セキュリティリスク
- クライアントから送信されるヘッダーは改ざん可能です。
- 信頼できないヘッダーをそのまま使うと、認証バイパスや情報漏洩の原因になります。
- 必要なヘッダーだけを取得し、値の検証やサニタイズを必ず行いましょう。
パフォーマンスへの影響
大量のヘッダーを取得するとメモリ使用量や処理時間が増加する可能性があります。
必要なヘッダー名だけを配列で指定して取得することが推奨されます。
まとめ
useRequestHeadersはNuxtのSSR環境でリクエストヘッダーを安全かつ簡単に取得できる強力なツールです。
認証情報の引き継ぎや多言語対応、カスタムヘッダーの活用など、実務での利用価値は非常に高い一方で、クライアントサイドでの利用不可やセキュリティ面の注意も必要です。
本記事で紹介したポイントや注意点を踏まえ、適切に使いこなすことで、Nuxtアプリケーションの信頼性と利便性を大きく向上させることができます。ぜひ実務に役立ててください。
useRequestHeadersはSSR限定の機能であることを忘れずに。クライアント側でヘッダー情報が必要な場合は別の方法を検討しましょう。
※このページは Nuxt.js 公式ドキュメントの翻訳ページです。
公式ドキュメントの該当ページはこちら:
https://nuxt.com/docs/3.x/api/composables/use-request-headers