ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Lotus Notes/Domino >

LDD Today

Domino: ブラウザーのキャッシュとレスポンス・ヘッダのルール

by John Chamberlain
レベル：初級者
対象：Domino 6
原文の掲載：2002年5月6日

LDD Today の原文（US）

インデックス

	レスポンス・ヘッダのルールとは？
	キャッシュについて理解する
	レスポンス・ヘッダのルールを作成する
	カスタムヘッダの設定
	レスポンスルールはキャッシュのためだけではない
	@SetHTTPHeaderの利用
	結論

ご注意：

このテクニカル概説はドラフトです。ここに記された内容はDomino 6プレリリース２で見ることができる機能について述べられています。Domino 6プレリリース２は機能が確定されたものではなく、2002年第3四半期のゴールドリリースまで改定されていく予定です。この内容は、それまでに最終更新される予定です。

このシリーズの前の記事である「Building Web applications in Domino 6: A tutorial on Web site addressing（US）」、「Building Web applications in Domino 6: Web site rules（US）」、「Building Web applications in Domino 6: Accessing and protecting the file system（US）」を読まれた方は、Dominoディレクトリーの新規ビュー「サーバー・インターネットサイト」のWebサイトルール文書の全般について知り、リダイレクション、代用（substitution）、ディレクトリーの各ルールの作成方法を理解されていると思う。この記事では、作成できる最後のルールのタイプとしてHTTPレスポンス・ヘッダのルールについて説明する。

この記事は、すべてのシステム管理者とDomino 6を使用してWebサイトを運営する計画のあるWebマスターにとって興味深い内容になっている。また、Dominoディレクトリーと管理タスクに慣れていることを前提としている。上記に示したこのシリーズの3つの記事を読むと参考になるであろう。

レスポンス・ヘッダのルールとは？

HTTPブラウザーのリクエストとサーバーのレスポンスは、常に転送データを説明するヘッダから始まっている。HTTPレスポンス・ヘッダのルールを使用すると、アプリケーションの設計者は、指定したリクエストに対し、Dominoが送信するレスポンスのヘッダをカスタマイズできる。

レスポンスのルールには、他のルールと比べて非常に重要な違いが1つある。DominoのHTTPサーバータスクは、受け取ったリクエストに対してリダイレクション、代用、ディレクトリーの各ルールを適用し、その後でリクエストを処理するためにアプリケーションに渡す。一方、レスポンスのルールは、送信するレスポンスに対して適用され、その直後にレスポンスがブラウザーに送信される。

レスポンスルールの最も重要な使い方は、ブラウザーのキャッシングを改善することである。アプリケーションの設計者は、キャッシュされるデータの有効性に関する重要な情報をヘッダに追加し、ブラウザーに提供できる。では、ブラウザーとサーバーのキャッシングについて詳しく調べるところから始めよう。

上に戻る

キャッシュについて理解する

まず、キャッシュとは何だろうか。大まかにいうと、キャッシュはメモリーまたはディスクの一領域で、プログラムがデータを再使用するために蓄えておくところである。処理時間、リソースの使用状況、転送の帯域幅などの理由で、データの作成や取得が困難な操作となる場合に、キャッシュの価値が高まる。インターネットなどのネットワーク環境では、データが生成されるソースマシン（Webサーバーなど）、データをリクエストするマシン（ユーザーのホームコンピュータ上のブラウザーなど）、ネットワークの中間の任意のノード（プロキシサーバーなど）で、キャッシュは維持される。

Webの世界では、現在のすべてのブラウザーはHTTPリクエストのレスポンスをキャッシュすることができる。ブラウザーでよく見る典型的なWebページは、通常、一度のリクエストでは得られず、数多くのリクエストの結果として得られる。たとえば、ページのHTMLにグラフィック要素へのリンクが多数含まれているときは、ブラウザーがそれぞれのリクエストを送信し、一つ一つの画像が取得される。ブラウザーは、各リクエストから返されたデータをキャッシュ内に個別に保存する。言い換えると、ブラウザーのキャッシュの最も小さい単位は、1回のHTTPレスポンスということになる（もちろん、ブラウザーはCookieや保存されたユーザー証明書などの他の情報もキャッシュに蓄えている）。

サーバーサイドのキャッシュ
サーバーでのキャッシュは、サーバーサイドのキャッシュと呼ばれ、状況が異なっている。サーバーは、ブラウザーに送信したレスポンスをキャッシュすることもできるが、レスポンスの生成に使用したデータとリソースをキャッシュする機会も持っている。このキャッシングはサーバーコードの多くの異なるレイヤーで行われ、実際には、オペレーティングシステムでも行われている。では、Dominoの典型的なリクエストである「/catalog.nsf/products?OpenView」について考えてみよう。このリクエストへのレスポンスを生成するために、Dominoはデータベースを読み取り、ビューの索引をHTMLに変換する必要がある。キャッシングは、次のときに行われる。まず、オペレーティングシステムがファイルシステムのページをキャッシュする、次に、Dominoがデータベースハンドル、設計要素（ビューのテンプレートなど）、ユーザー証明書をキャッシュする、さらに、ビューの索引自体がメモリー内で利用できる。

この低レベルのキャッシュの他に、Domino R5ではNSFリクエストへのHTTPレスポンス全体を「コマンドキャッシュ」という専用のキャッシュとして維持できる。しかし、Domino 6では、コマンドキャッシュが削除されている。なぜだろうか。これは、低レベルのキャッシュがすでに行われているとき、コマンドキャッシュは典型的なWebアプリケーションのパフォーマンスをあまり改善しないことがテストによって判明したからである。Domino 6では、NSFコアコードのパフォーマンスを改良する作業が十分に行われ、これによって高レベルのキャッシュを維持するメリットがほとんどなくなったのだ。

キャッシュをどこで維持するかにかかわらず、キャッシュの効率はタイムリーさとセキュリティーという2つの重要な原則に依存する。キャッシュを維持するプログラムは、データが最新の状態に保たれていることを保証し、キャッシュされたデータを適切なユーザーだけに表示することが必要である。たとえば、銀行のオンラインWebサービスで自分の口座の残高を見るケースを考えよう。このケースでは、2つのことが保証されなければならない。まず、常に最新の数字が表示されること。キャッシュに残っている先週の数字が表示されてはならない。次に、自分の口座の情報が表示されること。絶対に、別の人の口座が表示されてはならない。

キャッシュはこの2つの原則に従う必要がある。このことは、R5でのサーバーサイドのコマンドキャッシュがあまり効果的でないことの説明にもなる。Dominoは非常に動的で（データが定期的に変化する）、非常にセキュアな（データが多数のアクセス制御層で保護されている）アプリケーションをサポートするよう設計されている。このようなアプリケーションでは、HTTPレスポンス全体が完全に静的（スタテック）になる可能性や、公開できる（つまり、サーバーにキャッシュとして維持する価値がある）可能性は非常に少ない。それに比べ、設計要素やビューの索引など、レスポンスの作成に使用した小さな単位をキャッシュする方が、Dominoにとって効率が大幅に向上する。

ブラウザーのキャッシュ
以上は、サーバーサイドのキャッシュの話だ。では、クライアントサイド（ブラウザー）のキャッシュはどうなっているのであろうか。ブラウザーは、ヘッダのLast-Modified（最終更新日時）、Expires（有効期限）、Cache-Control（キャッシュコントロール）を見て、HTTPレスポンスのキャッシュ性（Chachability）を判断する。HTTPレスポンス・ヘッダのルールが役に立つのは、この点である。Domino 6におけるアプリケーションの設計者は、キャッシングヘッダを操作して、レスポンスのキャッシュ性を最大限に高めるルールを作成することにより、アプリケーションのパフォーマンスを大幅に高めることができる。つまり、アプリケーションの設計者は、ブラウザーがキャッシュをより効率よく維持するのを手伝うことができる。この方式の利点を最大限に活用するには、アプリケーションの設計者が、実際にどれだけアプリケーションが動的なのかを十分に把握しておく必要がある。Dominoサーバーとユーザーのブラウザーのどちらも、ユーザーに絶対に古いデータを見せないようにキャッシングに関してかなり慎重になるが、アプリケーションの設計者はアプリケーションの実際の動作について詳しく知っているので、ブラウザーにより多くのレスポンスをキャッシュさせることができる。

キャッシングヘッダはHTTP/1.1仕様のRFC2616で定義されている。また、これには、キャッシュを最新の状態に保つために、サーバーとブラウザーが従わなければならない一般的な手順の概要も示されている。

Last-Modifiedヘッダ
もっとも重要なのがLast-Modifiedヘッダで、これはリソースやレスポンスの生成に使用されたリソースがサーバー上で最後に変更された日時を示す。Dominoデータベースのページ要素を例にとって、このヘッダがどのように機能するのかを見ていこう。

1)	ユーザーは、?OpenPageコマンドを使用して、ブラウザーを介してページをリクエストする。
2)	Dominoはページを返し、ページが変更された日時を示すLast-Modifiedヘッダを含める。
3)	ブラウザーはページをローカルキャッシュに追加し、Last-Modifiedの日時をそれとともに保存する。
4)	ユーザーがそのページを次の回にリクエストしたときに、ブラウザーはIf-Modified-Sinceヘッダをリクエストに追加する。このヘッダは、キャッシュされたページのLast-Modifiedの日時を示す。
5)	If-Modified-Sinceの日時以降にページが変更されていないときは、Dominoはページを返さずに、HTTPステータスコードの304（Not Modified）だけを返す。このコードは、キャッシュされたページがまだ有効であることをブラウザーに示す。そして、ブラウザーはキャッシュされているページを表示する。
6)	ページが変更されているときは、Dominoは更新されたLast-Modifiedヘッダとともにページ全体を送り返す。ブラウザーは、新しいページでキャッシュを置き換え、Last-Modifiedの新しい日時を記録する。

これはシンプルな例だが、サブフォームや共有フィールドなどを含む文書のように、より複雑な要素をユーザーがリクエストしたときは、Dominoはコンポーネントごとに変更日時を確認しなければならず、最も新しい値をLast-Modifiedの日時として返す。

Expiresヘッダ
ExpiresヘッダはLast-Modifiedとは反対の関係にある。サーバーはExpiresヘッダを使用して、いつリソースの変更が予想されるのかをブラウザーに通知する。つまり、キャッシュされたレスポンスがどれだけの間有効であるかを示す。正確なExpiresヘッダはアプリケーションのパフォーマンスを大幅に向上させる。Expiresの期間内に、キャッシュされたレスポンスへのリクエストが再び行われると、ブラウザーはIf-Modified-Sinceリクエストを送ることなく、キャッシュされているレスポンスをすぐに再表示すればよいからだ。このため、Expiresヘッダによってキャッシュされているレスポンスを再使用すると、帯域幅もサーバーの処理時間もまったく使用されない。

もちろん、サーバーは将来のことを予測できないので（将来的には量子コンピュータによって可能になるかもしれないが、現時点ではこの制限に従う他はない）、Expiresヘッダを自動的に生成することは奇妙なことである。Dominoは、データがいつ変更されるのか、またはアプリケーション開発者がいつ設計要素を変更するのかを知ることはできない。このため、Dominoは将来の日付を持ったExpiresヘッダを送ることはない。Dominoは、キャッシュされることのない、過去の日付を持ったExpiresヘッダをレスポンスとして返す。これは、いくつかのブラウザーが望んでいる動作であり、将来の日付を自動的に生成することは問題外となる。

しかし、アプリケーションの開発者は、サーバーに対して大きなアドバンテージを持っている。アプリケーションについての知識があるので、将来を予測することができるのだ。この点で、レスポンスルールが現実的なものとなる。設計者は、リソースの変更時期の予測に基づいて、Expiresヘッダをレスポンスに追加するルールを定義できる。更新が定期的に行われるときは、設計者の知識は非常に正確になるであろう。また、ユーザーにとって常に最新のデータを見ることが重要でないときは、より一般的で、受け入れやすいものになるだろう。Expiresヘッダの例については、後で詳しく見ていくことにする。

Cache-Controlヘッダ
Cache-Controlヘッダは、ブラウザーとプロキシサーバーのキャッシュに対し、明確な命令を与える。このヘッダにはRFC2616で規定された数多くのオプションがあるが、Dominoは"no-cache"と"private"の2つのオプションだけを生成する。

"Cache-Control: no-chache"は、レスポンスが現在の時刻に依存したり、認証されたユーザーに一意の場合など、キャッシュされるべきでないことを明確に指定するレスポンスに追加される。Cache-ControlはHTTP 1.1で規定された新しいヘッダである。HTTP 1.0仕様では、キャッシュしないレスポンスについては、"Pragma: no-cache"が定義されていた。このため、DominoはHTTP 1.0のリクエストに対しては、"Cache-Control: no-cache"の代わりに"Pragma: no-cache"を使用する。

"Cache-Control: private"は、キャッシュ可能だが、それがブラウザーの特定の設定（たとえば、ブラウザーの言語設定）に依存するレスポンスに追加される。"private"のレスポンスをキャッシュするかどうかは、ブラウザー側が決めることになる。HTTP1.0には"Cache-Control: private"と等価のヘッダがないため、DominoはHTTP1.0レスポンスに対しては、ダウングレードしてPragma: no-cache"を使用する。

もし、アプリケーション設計者が、Cache-Controlヘッダに対するDominoのデフォルトの動作が気に入らないときは、レスポンスルールを使用してDominoの動作を変更できる。この例を以下で説明する。

現実でのキャッシュ
詳しい説明に入る前に、大きな注意点がある。これまでのキャッシュの議論はかなり直線的で、現実には物事はそう単純ではない。まず、どのブラウザーでもキャッシュ機能の実装が少し異なっている。実際に、同じブラウザーでもバージョンが違うと、キャッシュの動作も少し異なる。また、ブラウザーにはユーザーがキャッシュを制御する機能があり、正しいオプションを選択することが非常に重要になる。

たとえば、次に示す図はMicrosoft Internet Explorer 5.5のキャッシュ設定の画面で、「Automatic」オプションのヘルプが表示されている。このオプションを選択すると、ページが最後にアクセスされたのが前のブラウザーセッションまたは前日のときにだけ、IEはキャッシュされたページの有効性をチェックする（つまり、If-Modified-Sinceヘッダを送信する）。このため、現在のセッションでユーザーが同じページに複数回アクセスしても（たとえば、順番に戻っていくか、履歴のリストから選択して戻る）、IEはページをチェックしない。ブラウザーの不適切な設定は、サイト管理者やLotusのサポート担当者にとって不幸なことである。われわれは、キャッシュの動作不良について報告をよく受け取るが、調べてみると、Dominoやカスタマーのアプリケーションの問題よりも、ブラウザの不適切な設定が原因であることの方が多い。

IE5.5 caching settings

IE5.5のキャッシュ設定画面

また、ユーザーは独自のキャッシュ設定をしたプロキシサーバーを介してアクセスしていることもあるので、これも問題の原因となりうる。個人的な経験から言うと、すべてのブラウザーのあらゆる設定のもとで、キャッシュの動作を同一に揃えること自体無理なことである。「廃棄されたデータを表示するリスクを負うよりも、何もキャッシュしない方がよい」という慎重すぎる態度では、いつも誤ることになりそうだ。したがって、Dominoのデフォルトの動作を変更するのは、何を行うかを本当に理解しているときにだけにするべきである。

それでは、何を行うかを十分に理解しているものとして、HTTPレスポンス・ヘッダのルールを使用してブラウザーのキャッシュを改善する方法を見ていこう。

上に戻る

レスポンス・ヘッダのルールを作成する

Webサイトのルール文書の基本については、前の記事で十分に説明した。簡単に復習すると、Webサイトルールは、Dominoディレクトリーの「サーバー・インターネットサイト」ビューで定義されたWebサイトへの返答文書である。サイト用のWebサイトルールを作成するには、サイト文書を開き、「Webサイト」アクションボタンをクリックし、「ルールの作成」を選択する。これによって、空のWebサイトルール文書が開かれる。「ルールのタイプ」フィールドで「HTTPレスポンス・ヘッダ」を選択すると、フォームは次のような表示となる。

Web Site Rule document

「ルールの作成」設定画面

「Description」フィールドには、ルールを識別し、説明するようなテキストを入力する。「Incoming URL pattern」フィールドで、一致するURLを検出するテンプレートを指定する。レスポンス・ヘッダのルールには、代用（substitution）とリダイレクションのルールが適用された後の最終的な形のURLに対し、パターンのマッチングが行われる。たとえば、/help*/を/support.nsf/helpview/*に変形する代用ルールがあり、このレスポンスにルールを適用したいときは、レスポンスルールのパターンとして/support.nsf/helpview/*を指定する。

パターンには、ワイルドカード文字として、1つまたは複数のアスタリスクを含められる。たとえば、パターン/*/catalog/*.htmは、/petstore/catalog/food.htm、/clothing/catalog/thumbnails.htmといったURLにマッチする。レスポンスルールには、ワイルドカードは必須ではない。このため、特定のリソース（たとえば、/cgi-bin/account.pl）だけに適用するルールを作成できる。他のルールと同様に、インバウンド用のパターンにはクエリー文字列は含められない。

レスポンス・ヘッダのルールは他のルールとは異なり、URLパターンだけでなく、HTTPレスポンスステータスコードも指定する必要がある。「HTTPレスポンスコード」フィールドで、1つ以上のステータスコードを入力する。たとえば、次のレスポンスではステータスコードが200なので、リクエストが成功したことを示す。

HTTP/1.1 200 OK
Server: Lotus-Domino
Date: Fri, 15 Mar 2002 14:25:30 GMT
Content-Type: text/html
etc.

すべてのステータスコードの一覧はRFC 2616で定義されている。Domino Webサーバーは、これらのコードのサブセットを返す。もっとも一般的に用いられるコードを以下に示す。

200: OK (リクエストは成功)
206: Partial content (バイトレンジのリクエストが成功したレスポンス)
302: Found (外部のリダイレクション)
304: Not modified (ページは未変更)
400: Bad request (多数のエラーの可能性)
401: Unauthorized
403: Forbidden
404: Not found
405: Method not allowed (WebDAV は無効)
500: Internal server error (他のコードに一致しないエラー)

次のフィールドでは、Expiresヘッダを設定する。以下に示す3つのオプションがある。

1.Don't add header
カスタムヘッダ（以下で説明）を追加するだけの目的でルールを作成するときは、このオプションを選択する。しかし、レスポンスには、これまでに説明したように、Dominoが生成したExpiresヘッダが含まれる。また、リクエストがCGIまたはサーブレットを起動したときは、アプリケーションによって生成されたExpiresヘッダが含まれることがある。

2.Add header only if application did not
このオプションを選択すると、HTTPタスクはレスポンスにExpiresヘッダがすでに含まれているかどうかを判断する。含まれていない場合は、定義されたルールに従ってExpiresヘッダを追加する。

3.Always add header
HTTPタスクは、常にExpiresヘッダをレスポンスに追加する。ヘッダがすでにあるときは、追加したヘッダに置き換えられる。

後半の2つのオプションのいずれかを選択すると、ヘッダ値の日付を指定するオプションのセットが表示される。時刻の部分は常に午前０時の1秒前（23:59:59 GMT）にセットされる。日付は、何日後かを指定するか、特定の日付を指定する。

最初のオプションは「Specify as number of days」で、現在のシステム日付からn日数後の日付（nは指定した日数）がExpiresの値としてセットされる。たとえば、5日を指定すると（下図参照）、2002年6月3日（月）に生成されたレスポンスには、次のExpiresヘッダが追加される。

Expires: Sat, 8 Jun 2002 23:59:59 GMT

Specify as number of days options

オプション「Specify of number of days」

2番目のオプションは「Specify as date」で、このオプションを選択すると、カレンダーコントロールが表示され、特定の日付を選択できる（下図参照）。この例では、マッチするレスポンスに次のヘッダが追加される。

Expires: Tue, 18 Mar 2003 23:59:59 GMT

Specify as date options

オプション「Specify as date」

Expiresヘッダの例
レスポンス・ヘッダのルールを使用してExpiresヘッダを追加することで、効率が上がる典型的なシナリオを見ていくことにしよう。この例では、アプリケーションデータベースshopping.nsfには、ほとんど変わらないイメージリソースがある。また、イメージは見た目を良くするために使われているだけで、アプリケーションの機能にとってはあまり重要ではない。このため、ユーザーが古いイメージを見ても、深刻な影響は考えられない。このようなケースでは、常に10日後の日付のExpiresヘッダを追加するようなルールを作成すると、使い勝手が向上するだろう。

Description:	Product catarog images
Type of rule:	HTTP response headers
Incoming URL pattern:	/shopping.nsf/.gif
HTTP response codes:	200,206
Expires header:	Always add header Specify as number of days Expires after 10 days

上に戻る

カスタムヘッダの設定

レスポンス・ヘッダのルール用のWebサイトルール文書の一番下の部分には、カスタムヘッダのセクションがあり、合計3つまでのHTTPヘッダを定義して追加することができる。各ヘッダごとに、名前（最後のコロンは付けない）と値を指定し、さらに、同じ名前の場合は既存のヘッダを置き換えるかどうかを指定する。これらのフィールドの一般的な用途として、これまでに説明した、Cast-Modified、Cache-Control、Pragmaといったキャッシュヘッダの制御が考えられる。ここでは、2つの例を取り上げる。

最初の例として、グラフィックイメージのシナリオを再び取り上げよう。前に説明したように、DominoがCache-Controleヘッダで使用するのは"no-chache"と"private"の2つだけだ。RFC2616では、"public"というオプションも定義されている。これは、すべてのユーザーで共有するキャッシュ内にレスポンスを置けることを示す（これと反対が"private"）。ほとんどのブラウザーとキャッシングプロキシでは、"public"がデフォルトとして設定されている。しかし、レスポンスを必ず共有キャッシュ内に置きたいときは、自分でCache-Controlヘッダを追加すればよい。Webサイトルール文書で完成したこのルールは次のようになる。

Setting a custom Cache-Control header

サイトルール「レスポンスを必ず共有キャッシュ内に」

すでに設定されているExpiresヘッダの他に、カスタムヘッダセクションにCache-Controlヘッダの名前と値が追加されているのがわかる。

2番目の例として、レスポンスをキャッシュに入れたくないシナリオを考えてみよう。たとえば、営業部員用にサーブレットアプリケーションを実行するものと仮定する。このサーブレットを使用すると、営業担当者はカスタマーのアカウント情報にアクセスできる。このサーブレットは外部のベンダーから入手したものだが、HTTPヘッダを常に正しく設定する必要がある。営業担当者が常に最新のデータを得られるようにするために、キャッシングしないようにサーブレットのヘッダを書き換えるルールを作成することにした。

Description:	Customer account sarvlet
Type of rule:	HTTP response headers
Incoming URL pattern:	/sarvlet/salesaction*
HTTP response codes:	200,206
Expires header:	Always add header Specify as number of days Expires after 01/01/90
Custom headers:	Name: Cache-Control Value:no-cache Ovverride: yes Name: Pregma Value: no-cache Override: yes Name: Last-Modified Value: Fri, 01 Jan 1990 00:00:01 GMT Override: yes

ルールにはCache-control: no-cacheとPragma: no-cacheの2つのヘッダが含まれ、HTTP/1.1とHTTP/1.0の両方のキャッシュメカニズムでキャッシュされないようにカバーしている。Last-ModifiedヘッダとExpiresヘッダでかなり過去の日付をセットしているのは、たとえブラウザーまたはプロキシがレスポンスをキャッシュした場合でも、再度リクエストされたときに、キャッシュされているバージョンを期限切れと認識させるためである。

上に戻る

レスポンスルールはキャッシュのためだけではない

これまでは、ブラウザーのキャッシュという観点からレスポンスルールを説明してきた。しかし、レスポンスルールは、キャッシュ以外の状況でも有効に使える。たとえば、RFC2616は、HTTPアプリケーションに独自のヘッダを定義することを許可している。ここでは、ユーザーのブラウザー内で実行し、Webアプリケーションへのインタフェースとして機能するJavaアプレットを作成するものとしよう。このようなアプレットに、新しいレスポンス・ヘッダ"Error-Message"を定義できる。このヘッダは、エラーが発生したときに、その内容を示すテキストをアプレットに通知する。そして、次のようなルールを作成すると、ユーザーがアプリケーションにアクセスする権限を持たないときに（このような場合は、サーバーはHTTPレスポンスコード401 Unautorizedを返す）、アプレットに特定のメッセージを表示させることができる。

Description:	Unauthorized message for budget application
Type of rule:	HTTP response headers
Incoming URL pattern:	/budget.nsf*
HTTP response codes:	401
Custom headers:	Name: Error-Message Value: You are not authorized to access the budget application. Please contact the accounting department help desk.

Description:	Unauthorized message for personal application
Type of rule:	HTTP response headers
Incoming URL pattern:	/personal.nsf*
HTTP response codes:	401
Custom headers:	Name: Error-Message Value: You are not authorized to access the personnel application. Please send an email to Roger Jones in Human Resources.

上に戻る

@SetHTTPHeaderの利用

Dominoデータベースへのリクエストに対し、HTTPレスポンス・ヘッダを設定するもう1つの方法として@SetHTTPHeader関数がある。これも、Domino 6での新機能だ。たとえば、フォーム上に次の式を持つ計算フィールドを作成してみよう。

@SetHTTPHeader("Cache-Control";"no-store")

すると、HTTPタスクは、?OpenForm URLや?OpenDocument URLなどこのフォームを使用するリクエストへのレスポンスに、Cache-Controlヘッダを追加する。@SetHTTPHeaderは、Dominoディレクトリーの設定を変更しなくてもよいので、HTTPレスポンス・ヘッダのルールよりも優れている。アプリケーションの設計者はディレクトリーを変更する権限を持たないことがあり、このような場合は、サイトの管理者に依頼してルールを作成してもらわなければならない。しかし、@SetHTTPHeaderはDominoの式が評価されるときにしか使用できないのに対し、ルールはアプリケーションの任意の部分で使用できる。

「Domino Designer 6 Help」に、@SetHTTPHeaderと、その読み出し専用バージョンの@GetHTTPHeaderについての情報が掲載されている。

上に戻る

結論

上記のHTTPレスポンス・ヘッダのルールの記事をもって、Domino 6のWebサイトルールに関する説明は完了する。他のタイプのルールについても理解を深めるために、このシリーズの前の記事も読み返して欲しい。すべてのタイプのルールを熟知することにより、Webアプリケーションの管理、ユーザーのナビゲーション、パフォーマンスの各面で効率が改善し、Domino 6のWebサイトインタフェースの真の実力が発揮されるであろう。

作者について
John ChamberlainはDomino 6 Web Serverチームのシニアソフトウェアエンジニアである。彼は初期の頃からチームで活躍しており、最近、Lotus社員として勤続15年の表彰を受けている。

上に戻る