WEBサーバーへのLB（ロードバランス）をBIGIPで行っているサイトでは、Sorry画面を実装することが多いと思います。
（Sorry画面とはWEBサーバーが何らかの障害で利用できなくなった場合にブラウザに応答する代替画面のことです。）
今回はSorry画面を実装する際のテクニックを紹介します。
HTTP::respondでSorry画面応答する場合のキャッシュOFF
Sorry画面を応答する方法として、HTTP::redirectメソッドで他サイトにリダイレクトさせ、Sorry画面を表示させる方法と、HTTP::respondメソッドを使って、リクエストをリライトし、Sorry画面でレスポンスする方法があります。
リダイレクトの場合は、ブラウザに一度、30xコードでレスポンスしますから、リクエストURLがSorry画面のものに変化します。
そのため、キャッシュを意識することはありません。
一方で、リライトの場合は、ブラウザからリクエストしたURLのレスポンスがSorry画面に置き換わってしまうため、Sorry画面としてキャッシュしてしまいます。そのため、障害復旧後に通常のアプリケーションへのアクセスに切り替わっても、ブラウザキャッシュやProxyキャッシュの効果でSorry画面が表示しつづけてしまうという事象が発生します。
そこで、HTTP::respondメソッドでSorry画面応答する際には、キャッシュを抑止する対応が必要になります。
Sorry画面のHTML内にキャッシュOFFのメタタグを入れたらいいじゃないかという意見もあるかと思いますが、HTMLコードを解釈するブラウザでのキャッシュには効果があるかもしれませんが、Proxyキャッシュには効果が期待できません。
BIGIPでは以下のようにコーディングすることで、HTTPヘッダーにキャッシュOFF命令を加えることが可能です。
HTTP::respond 200 content [ifile get sorry] Content-Type "text/html" Cache-Control "private, no-store, no-cache, max-age=0" Pragma "no-cache"
上記例では、HTTP::respondメソッドで200ステータスでiFileをレスポンスとして応答させています。
※あらかじめSorry画面となるHTMLをBIGIPにFile登録してから、iRuleから利用できるファイル（iFile）として登録しておきます。
テクニックとしては、HTTP::respondメソッドを使う時にHTTPヘッダーに値を埋め込む時は、構文の後部に記載することで可能となる点を活用しています。上記のキャッシュOFFの命令の説明自体は本ブログで以前に記載しておりますので割愛します。
ついでですが、キャッシュOFFの命令を以下のように書くと、通常のレスポンス時には効果がありますが、HTTP::respond命令には効果がありません。
HTTP::header replace Cache-Control "private, no-store, no-cache, max-age=0" Pragma "no-cache"
HTTP::header replace Pragma "no-cache"
HTTP::respond 200 content [ifile get sorry] Content-Type "text/html"
余談ですが、Sorry画面を応答する場合、よく使われているイベントはLB_FAILDであると思います。
BIGIPv11では、LB_FAILDイベントでHTTP::respondで応答できるコンテンツサイズに制限があります。
リッチなSorry画面を応答したい場合は、LB_FAILDイベントではリダイレクトを使うことをお勧めします。
