基本

非常に単純なテスト アクションを作成しました。

付属のアクションと小枝は今は重要ではありません。

テスト

Varnish はSurrogate-Control: content="ESI/1.0"、応答にヘッダーを必要とします。何が起こるか見てください：

応答:

すべて大丈夫です！しかし、ヘッダーを見てください：

出力：

Surrogate-Controlヘッダーがない！

\Symfony\Component\HttpKernel\HttpCache\Esi クラス

コンテンツに文字列Surrogate-Controlが含まれている場合、ヘッダーを追加する非常に単純な関数があります。<esi:include

しかし、そうではありません！if は「真」です。これで呼び出すと：

応答:

出力：

ヘッダーはどこSurrogate-Controlにありますか? :-o

その他のテスト:

と$response->headers->set('Surrogate-Control', 'content="ESI/1.0"');(!!!) header('Test: test OK'):

• 【1】場所：WORK！
• [2] 元の場所: 動作しません:(
• 【3】場所：WORK！

Ok。したがって、ヘッダーの変更が にあるIF場合、機能しません。なんで？

魔法

条件を変更する$response->getContent()と'test <esi:include test'、ifすべてが正常に機能します。ResponseクラスgetContent()関数:

理解できない ：-/

Varnish ESI で特有の問題が発生しています。

私のサイトの各ページには、(ログインした) ユーザーのアカウント情報を吐き出す ESI フラグメントがあります。

ブラウザが Cache-Control: no-cache / Pragma: no-cache (force refresh) をサーバーから ESI コンテンツを要求するときに送信しない限り、Varnish はユーザー セッション ESI フラグメントのキャッシュされた結果を返しているようです。

私の vcl_recv には、これをバイパスするルールが含まれています。

vcl_fetch にもルールがあります。

基本的に、これはブラウザ側からの動作です。

Cache-Control: max-age=0 => Varnish はキャッシュされた ESI フラグメントを返します

Cache-Control: no-cache / Pragma: no-cache => Varnish はサーバーから ESI フラグメントを取得します

私はそれを理解できないようで、かなり明白な構成を見逃したような気がします。

Symfony2 アプリケーションでは、再利用可能なブロックを render_esi でレンダリングします。このようなテンプレートがあります:

もちろん、製品の詳細ページでも render_esi を使用しています。

ネットワーク パス参照<esi:include src="url" />を使用して を実行できないことがわかりました。インクルードでエラーを返します。

プロトコル/スキームを省略した絶対 URL を含めることは可能ですか?

呼び出しページのプロトコル/スキームに応じて、httpまたはhttps経由でページを含める必要があります

(したがって、http://example.com/containerに含める場合は http://example.com/included を含め、https://example.com/containerに含める場合は https://example.com/included を含めます.com/コンテナ)

私はワニスを解決しようとしています。

私の問題です。ワニスを使用してキャッシュしたいメインのリクエスト/レスポンスがあります。HTML 構造内に ESI タグがあります。たくさん持っていきたいです。より長い ttl を持つ 1 つのタグとttl=0s;を持つ他のタグ （ログインボックス付きのESIコンテンツ）。

とにかく、ワニスがメインのリクエストにヒットするようにしたいのですが、バックエンドの ESI コンテンツにヘッダーなどの情報を求めます。ESI コンテンツが戻ってきたら (最初は親リクエストで、次に ESI によるサブ リクエストであると理解しているため)、何らかのコミュニケーションが必要です。

beresp に加えられた変更は、後で obj に保存されることに注意してください。resp.* 変数は、これから返されるもののコピーです。おそらく obj のコピーです。つまり、 beresp への変更は、将来の obj.* および resp.* 変数に影響します。同様のセマンティクスが req.* と bereq に適用されます。. ベレック。元のリクエストから作成された「バックエンド リクエスト」です。若干異なる場合があります。たとえば、Varnish は HEAD リクエストを GET に変換できます。

https://www.varnish-software.com/static/book/VCL_functions.htmlから

例: ESI サブリクエストのレスポンスにヘッダーがある場合"X-ESI-Cookie"、それをメイン レスポンスに渡したい。

ESIについて何かを知る唯一の方法はreg.esi_level.

基本的に私が達成したいことは次のとおりです。

ワニスでページ全体をキャッシュしたいのですが、セッション管理のために ESI コンテンツをパイプしますが、セッションを維持するには、サブ (ESI) から親の応答にいくつかのヘッダーを渡す必要があります (ただし、それは明らかだと思います)。

ワニスのリクエスト (親と ESI) は別々に処理されると思います。つまり、通信する機会がありません。Varnish は、タグを ESI 応答からの html に置き換えるだけです。そうですか？

私はそれに対する解決策がないと信じ始めていますが、誰かがこの問題に対するより良い解決策を持っているかもしれません:セッションを維持するには? いくつかの解決策を見つけましたが、私のニーズに合ったものはありません。(私は Fake-Session を信じていました。ID はいくつかの C コードを使用して Varnish によって生成されましたが、ロックはありませんでした)。

現在のsymfony2アプリを採用する方がはるかに簡単なので、そのようにしたいと思います。とにかく、symfony2 がこの種の機能を予期していなかったとは信じられません。私のページは、いくつかのウィジェット (ESI コンテンツ) を除いて、主に静的です。

オブジェクト変数に ESI コンテンツ (リクエスト、コンテンツ、およびレスポンス) があると非常に便利です。

ワニス オブジェクトに ESI コンテンツに関する情報がまったくないなんて信じられません。

*.vcl 構成で解決策を探していることに注意することが重要ですが、どの解決策でもうまくいきます。

前もって感謝します。