VCL コードを書く

スニペットを使う場合でもカスタム VCL を使って VCL コードを書く場合でも、言語内で利用可能な機能は同じです。このセクションでは、最も一般的な VCL ユースケースのいくつかをまとめています。

ヒント:VCL の一般的なユースケースは、コード例ギャラリーで多数紹介siています。ベストプラクティスガイドは、落とし穴を回避し、より安全でセキュアなエッジコードを作成する方法を理解するのに役立ちます。また、当社の Fiddle ツールを使えば、Fastly にログインしなくても VCL コードをインタラクティブに記述・実行できるため、アイデアを試したりテストしたりする場として活用できます。

ヘッダーの操作

setunset ステートメントを使用すると、リクエストとレスポンスの HTTP ヘッダーを設定および解除できます。例えば、vcl_fetch では次のように書くことができます。

sub vcl_fetch { ... }
Fastly VCL
set beresp.http.Cache-Control = "public, max-age=3600";
unset beresp.http.x-goog-request-id;

{OBJ-NAME}.http.{HEADER-NAME} パターンは reqbereqrespberesp、および obj で利用可能です。それぞれの変数がどこで使用できるかの詳細は、VCL 変数に関する説明を参照してください。ただし、一般的には以下のようになります。

ヘッダーを追加/削除するには......これを使用してくださいユースケースの例
クライアントのリクエストvcl_recvreq.http.{NAME}Cookie ヘッダーを削除して認証情報を除去
後で参照するデータを VCL に保存
バックエンドリクエストvcl_missvcl_passbereq.http.{NAME}認証ヘッダーを追加
バックエンドレスポンスvcl_fetchberesp.http.{NAME}ブラウザのキャッシュの有効期限 (TTL) を設定
余分なオリジンレスポンスヘッダーを削除
クライアントレスポンスvcl_deliverresp.http.{NAME}Cookie の設定
シンセティックレスポンスvcl_errorobj.http.{NAME}synthetic レスポンスのコンテンツタイプを設定

URL とクエリ文字列

req.url 変数はクライアントから要求される URL (パスとクエリ) を含み、バックエンドにリクエストを出す際に bereq.url にコピーされます。パスとクエリは、req.url.pathreq.url.qs として個別にアクセスできます。クエリパラメータを操作するには、querystring.getquerystring.set を使用することを検討してください。querystring.filter は不要なクエリパラメータを削除できます:

URL パスに正規表現を使用することは、 req.backend を設定することでリクエストを異なるバックエンドにルーティングするための一般的な方法です:

Cookie

Cookie ヘッダーはカンマ区切りの個別 Cookie リストなので、サブフィールドアクセサシンタックスを使って名前付き Cookie にアクセスできます。多くの場合、これを正規表現の一致と組み合わせて、構造化された Cookie 値の一部を抽出すると便利です。例えば、52b93cff.165826435.d783dad8-ebb9-4475-b6fb-68ce83f90f12 のような値を持つ auth Cookie がある場合、以下の VCL を使って auth Cookie を分離し、その各部分を異なる HTTP ヘッダーに抽出することができます。

sub vcl_recv { ... }
Fastly VCL
if (req.http.cookie:auth ~ "^([0-9a-f]+).(\d+).([\w-]+)$") {
set req.http.Auth-SessionID = re.group.1;
set req.http.Auth-CreditCount = re.group.2;
set req.http.Auth-DisplayName = re.group.3;
}

Cookie を書き込むには、通常 vcl_deliver で、クライアントのレスポンスに Set-Cookie ヘッダーを構築します。set を使用すると、同じ名前の既存のヘッダーが上書きされます。そのため、同じレスポンスで複数の Cookie を設定する場合は、代わりに add を使用してください。レスポンスに Cookie を設定する際には、クライアントや下流のエンティティがそれをキャッシュできないようにするのが賢明です。

sub vcl_deliver { ... }
Fastly VCL
add resp.http.set-cookie = "auth=52b93cff.165826435.d783dad8-ebb9-4475-b6fb-68ce83f90f12; max-age=86400; path=/";
set resp.http.cache-control = "private, no-store";

ログ機能

Fastly は、さまざまな特定のベンダーや汎用エンドポイントへのデータログ記録に対応しています。VCL では、log ステートメントを使用して、VCL コードのどこからでもLogメッセージを発行できます:

log "syslog " + req.service_id + " my-log-endpoint :: " + req.url;

VCL のすべての Log ステートメントは log "syslog {service_id} {log_endpoint_name} :: {log_message} という形式を取ります。ログエンドポイントの設定と使用方法の詳細については、ログ記録の概要を参照してください。

キャッシュのコントロール

Fastly は Cache-ControlLast-ModifiedExpires などのオリジンレスポンスで送信されるフレッシュネス関連の HTTP ヘッダーを尊重します。vcl_fetch の VCL を使用して beresp.ttlberesp.stale_while_revalidateberesp.stale_if_error の値を設定することで、この動作をオーバーライドできます。

sub vcl_fetch { ... }
Fastly VCL
set beresp.ttl = 30m;

HTTP ヘッダーや VCL 内の明示的な指示に関わらず、レスポンスの HTTP ステータスがキャッシュをサポートしない場合、キャッシュは無効になることがあります。200 (OK) レスポンスはキャッシュ可能とみなされますが、500 (内部サーバーエラー) はキャッシュ可能とはみなされません。この決定は beresp.cacheable 設定で変更できます。詳細については、HTTP セマンティクスの概要をご覧ください。

重要:VCL を使ってCache-Controlなどのヘッダーの値を設定しても、Fastly によるレスポンスキャッシュの有無や期間には影響しません (代わりにberesp.ttlを使用してください)。ただし、レスポンスに Cache-Control ヘッダーを設定することは、エンドユーザーのデバイス上でレスポンスがキャッシュされるかどうかを制御する有効な方法です。キャッシュを完全に無効にするには、vcl_recv または vcl_fetch から return(pass) を実行してください。vcl_recv で行うことでリクエスト共有を回避できるため、パフォーマンスが向上します。

シンセティックレスポンス

シンセティックレスポンスを使用すると、カスタマイズされたエラーメッセージや API コールへのレスポンス、コンテンツのページ全体を作成することができ、robots.txt ファイルなどのサイト全体のメタデータにしばしば活用されています。シンセティックレスポンスの詳細については、シンセティックのドキュメントを参照してください。