- ルール式:
http.host == "example.com" and starts_with(http.request.uri.path, "/downloads/") - Host header > Rewrite to:
assets.example.com
トラブルシューティング
特定のURIパスに対して1つ以上のルール機能が有効になっている場合、challengeを発行する際には、チャレンジループを避けるために、ルール式で/cdn-cgi/challenge-platform/で始まるURIパスを除外する必要があります。
例えば、and演算子とstarts_with()関数を使用して、ルールのための複合式を定義します：
<OTHER_RULE_CONDITIONS> and not starts_with(http.request.uri, "/cdn-cgi/challenge-platform/")URLリライトを使用してURIパスを書き換えると、フィルター式にURIパスを含む場合、Origin Rulesなどの後に実行される他のルール機能に影響を与える可能性があります。
次のオリジンルールの設定を考えてみましょう：
次の設定で新しいURLリライトを構成した場合：
- ルール式:
http.host == "example.com" and starts_with(http.request.uri.path, "/downloads/") - Path > Rewrite to > Dynamic:
regex_replace(http.request.uri.path, "^/downloads/", "/")
オリジンルールはもはや/downloads/*パスに一致しなくなります。なぜなら、URLリライトはオリジンルールの前に実行され、URIパスが"/downloads/"から"/"に書き換えられるからです。
この状況を防ぐために、ルール式で生のフィールドを使用してください。生のフィールドはリクエスト評価ワークフロー全体で不変であり、以前に一致したルールのアクションの影響を受けません。
現在の例では、両方のルールでraw.http.request.uri.pathフィールドを使用できます：
URLリライト
- ルール式:
http.host == "example.com" and starts_with(raw.http.request.uri.path, "/downloads/") - Path > Rewrite to > Dynamic:
regex_replace(raw.http.request.uri.path, "^/downloads/", "/")
オリジンルール
- ルール式:
http.host == "example.com" and starts_with(raw.http.request.uri.path, "/downloads/") - Host header > Rewrite to:
assets.example.com
このようにして、2つのルールは意図した通りに機能します。さらに、最初のルールがURIパスの値を更新している場合でも、同じ式を2つのルールで使用することができます。
生のフィールドのリストについては、Fieldsリファレンスページを参照してください。