レスポンスヘッダーを追加する
カスタムのレスポンスヘッダーを使うと、特定のパスに一致するリクエストにHTTPヘッダーの指示を追加できます。 レスポンスヘッダーとは、リクエストされたコンテンツにどのように対応するかをブラウザに指示する、名前と値のペアです。 例えば、Access-Control-Allow-Origin ヘッダーを指定して、そのページに対してブラウザがアクセスを許可するドメインを指定できます。
このエントリを作成するには、Replit Appのルートディレクトリにある .replit ファイルに以下を追加します:
- path: リクエストされたリソースに一致するURLパスパターン
- name: HTTPヘッダー名
- value: HTTPヘッダーの値
.replit ファイルには、複数の deployment.responseHeaders エントリを追加できます。
設定の更新を適用するには、Replit Appを再公開してください。
予約済みヘッダー
Replitは以下のHTTPヘッダーを予約しており、これらを設定することはできません。カスタム404ページを作成する
カスタム404ページは、公開済みアプリ内のどのファイルやルールにも一致しないURLパスをユーザーがリクエストしたときに表示されます。 カスタム404ページを追加するには、Replit Appのルートディレクトリに404.html という名前のファイルを作成し、そこにページの内容を記述します。
ユーザーが存在しないURLパスにアクセスしようとすると、カスタム404ページのレンダリング済みHTMLが表示されます。
URLパスのリライトを定義する
URLリライトを定義すると、Replit Appがリクエストを処理する前にそのURLパスを変更できます。 元のURLはブラウザ上では変わらずに表示されますが、サーバーはリライトルールで定義されたリソースを読み込みます。 例えば、/app で始まるすべてのリクエストが /app/index.html ファイルの内容を読み込むように指定できます。
このエントリを作成するには、Replit Appのルートディレクトリにある .replit ファイルに以下を追加します:
- from: リクエストされたリソースに一致するURLパスパターン
- to: リライト後のパス。スタティックデプロイメント内のファイルに対応します。
.replit ファイルには、複数の deployment.rewrites エントリを追加できます。
サーバーはエントリを記載されている順に解釈し、重複するものは無視します。
設定の更新を適用するには、Replit Appを再公開する必要があります。
以下のセクションでは、URLリライトルールの制約について説明します。
パスのマッチング
リライトルールのfrom パラメーターと to パラメーターには、以下の制約が適用されます:
*がない限り、マッチは完全一致でなければなりません*はパスの残りの部分にマッチします*はパスの末尾でのみ有効ですfromパラメーターに*を含める場合、toパラメーターにも含めることで、マッチしたパスの部分を表すことができます
.replit ファイルに以下のリライトが含まれているとします:
/v1/about-us.html にアクセスすると、リライトによって /v2/about-us.html にあるファイルが配信されます。
シャドウイング
シャドウイングとは、リライトがスタティックデプロイメント内のファイルにも一致するURLパスにマッチした場合に発生する現象です。 この場合、クラウドサーバーはリライトを無視し、ファイルを直接配信します。 例えば、公開済みアプリに以下のファイルが含まれているとします:index.htmlabout.html
.replit ファイルには以下のリライトが含まれています:
/register.html にアクセスすると、サーバーはリクエストを /index.html にリライトし、そのファイルを配信します。
しかし、ユーザーが /about.html にアクセスした場合は、そのファイルがスタティックデプロイメント内に存在するため、サーバーはリライトを無視して about.html ファイルを配信します。