handle_errors

エラーハンドラーを設定します。

通常のHTTPリクエストハンドラーがエラーを返すと、通常の処理が停止し、エラーハンドラーが呼び出されます。エラーハンドラーは通常のルートと同様にルートを形成し、通常のルートでできることは何でもできます。これにより、HTTPリクエスト中のエラー処理において優れた制御と柔軟性を実現できます。たとえば、静的エラーページ、テンプレート化されたエラーページを提供したり、別のバックエンドにリバースプロキシしてエラーを処理したりできます。

リクエストのコンテキストはエラールートに引き継がれるため、サイトルートや変数など、リクエストコンテキストに設定された値はエラーハンドラーでも保持されます。さらに、エラー処理時には新しいプレースホルダーを使用できます。

エラーとして分類されるHTTPステータスでレスポンスを書き込む可能性のあるreverse_proxyなど、特定のディレクティブは、エラールートを*トリガーしません*。

独自のルーティング決定に基づいてエラーを明示的にトリガーするには、errorディレクティブを使用できます。

構文

handle_errors {
	<directives...>
}

• <directives...> は、HTTPハンドラーのディレクティブとマッチャーのリストで、1行に1つずつ記述します。

プレースホルダー

エラー処理中は、以下のプレースホルダーを使用できます。これらは、HTTPサーバーのエラールートのJSONドキュメントにある完全なプレースホルダーのCaddyfile shorthandです。

例

ステータスコードに基づくカスタムエラーページ（例：`404`エラーの場合は`404.html`というページ）。file_serverは、`handle_errors`で実行された場合、エラーのHTTPステータスコードを保持することに注意してください（事前にサイトにサイトルートを設定していることを前提としています）

handle_errors {
	rewrite * /{err.status_code}.html
	file_server
}

templatesを使用してカスタムエラーメッセージを書き込む単一のエラーページ

handle_errors {
	rewrite * /error.html
	templates
	file_server
}

一部のエラーコードに対してのみカスタムエラーページを提供する場合は、fileマッチャーを使用して、事前にカスタムエラーファイルが存在するかどうかを確認できます

handle_errors {
	@custom_err file /err-{err.status_code}.html /err.html
	handle @custom_err {
		rewrite * {file_match.relative}
		file_server
	}
	respond "{err.status_code} {err.status_text}"
}

HTTPエラーの処理とあなたの1日を素晴らしいものにすることに非常に適任なプロフェッショナルサーバーへのリバースプロキシ 😸

handle_errors {
	rewrite * /{err.status_code}
	reverse_proxy https://http.cat {
		header_up Host {upstream_hostport}
		replace_status {err.status_code}
	}
}

respondを使用して、エラーコードと名前を返すだけです

handle_errors {
	respond "{err.status_code} {err.status_text}"
}

特定のエラーコードを異なる方法で処理するには、handleを使用して相互排他性を実現しながら、expressionマッチャーを使用します

handle_errors {
	@404-410 `{err.status_code} in [404, 410]`
	handle @404-410 {
		respond "It's a 404 or 410 error!"
	}

	@5xx `{err.status_code} >= 500 && {err.status_code} < 600`
	handle @5xx {
		respond "It's a 5xx error."
	}

	handle {
		respond "It's another error"
	}
}