2011-12-22 5 views
0

ob_end_flush()は暗黙のセッションクローズを引き起こすようです。これは意図された動作ですか?答えは「はい」と思いますが、何とかそれを防ぐことができますか?PHP:ob_end_flush()end session

ここで私が遭遇した問題の説明です。私は、カスタムセッションハンドラを使用するフレームワークを使用していますが、私はこの場合重要ではないと思っています。実際の問題は、フレームワークコードob_end_flush()のある時点で呼び出されたときに発生します。カスタムセッションハンドラの呼び出しを記録することによって、私はセッションの書き込みと終了がこの場合呼び出されることに気付きました。 Zend Debuggerでデバッグすることさえできないので、error_logでログするだけです。だから、ob_end_flush()セッションとのやりとりが続けられた(私は間違っているかもしれませんが、それでもなおそうです)、その状況では、前のセッションが既に閉じられているときに、新しいIDを持つ新しいセッションが開始されます。現時点ではCookieが設定されていないため、新しいセッションに新しいIDがあります。その結果、2つの異なるIDを持つ2つの別々のセッションが得られました。

私にとって最良の解決策は、暗黙的なob_end_flush()の動作を無効にすることですが、私はすべての回答を受け入れます。

ありがとうございます。

+1

'ob_end_flush()'はセッションを終了しません。すべてのフレームワーク回避策なしで小さなスクリプトで確認できます – zerkms

+0

本当に、本当ですか?それを確認する必要があります。たぶん私は間違っているが、私はob_end_flush()でブレークポイントを設定しているだけで、新しいセッションファイルが作成された直後に "ステップオーバー"キーを押す(カスタムセッションのwrite()を行う)。しかし、私はwrite()コールにはアクセスできません。なぜなら、デバッガはそこには存在しないからです。 – Stranger

答えて

0

少し間接的な回答ですが、要求全体をバッファリングする目的で出力バッファを開始するのが一般的な方法です(と推奨される方法もあります)。そうすることで、コンテンツの "出力"を開始した後も、セッションの使用やヘッダーの設定(リダイレクトを含む)を続けることができます。これはあなたの暗黙のセッションクローズの問題を処理する必要があります。ブートストラップの先頭にob_start()コールを追加するだけです。

+0

フレームワーク・コードでは、正しい場所ですでにob_start()を実行しており、要求全体をバッファしています。 session_write_close()がob_end_flush()で一度呼び出され、リクエスト処理の最後に(実行するコードがもうない)問題が(少なくとも私が見ているように)問題になります。 上記のzerkmsは、ob_end_flush()はセッションを終了しないと言いました。そうなら、私はちょっと混乱しています。 – Stranger

+0

まあ、それは確かに "一般的な練習"ですが、それはどのような手段でも推奨されていません。唯一の良い習慣は、理由なしに決して出力を行うことのないアプリケーション設計を持つことです。 –

+1

@ Col.Shrapnel、不一致は間違っていませんが、出力バッファリングが絶対に推奨されるいくつかの使用例を明確に指摘できます。私はむしろここに1つの良い練習があると述べているのを見て驚いています。明らかに、ベストプラクティスは文脈上決定される。 – Kenaniah