每次页面加载时,Zend_Session 和 Zend_Log _Db 都会写入数据库两次

发布于 2024-10-16 01:27:38 字数 939 浏览 5 评论 0原文

网络上散布着很多类似问题的例子,但他们的解决方案似乎都没有解决这个特定的变化。任何建议将不胜感激。

通常出现此问题的原因是,恶意链接导致对 favicon 或 css 文件等资源的请求多次命中调度程序,从而导致多个调度进程,从而导致数据库中出现多行。

我已经检查过这个非常简单的示例页面上的所有链接实际上都解析到它们指向的资源。

会话处理程序设置如下:

Zend_Db_Table_Abstract::setDefaultAdapter($db);
Zend_Session::setSaveHandler(new 
            Zend_Session_SaveHandler_DbTable($config->session->toArray()));

数据库日志记录设置如下:

$writer = new Zend_Log_Writer_Db($db, $config->log->tableName, 
            $config->log->columnMap->toArray());
$logger = new Zend_Log($writer);

两个对象均已正确设置,并且可以从数据库读取和写入。一切都只会发生两次。如果我将测试日志消息放在应用程序中的任何位置,它就会被写入数据库两次。如果我每次调用索引操作时都会增加三个变量 - 一个存储在会话中,一个通过 Zend_Registry 对象传递,另一个本地到 indexAction - 只有会话变量会增加 2。Apache 访问日志显示正确的数量从页面加载触发的请求,并且所有请求都有 200 或 304(不变)的良好响应代码。

我尝试禁用所有头链接。 我尝试过完全禁用布局。 我已将所有内容本地化到调度程序并在调度运行之前退出。

在所有情况下都会发生额外的写入/增量。 有什么想法吗? 预先感谢您的任何帮助。

There are plenty of examples of similar problems littered around the web but none of their solutions seem to fix this particular variation. Any suggestions would be appreciated.

Usually this problem occurs because a rogue link is causing a request for a resources like a favicon or css file to hit the dispatcher more than once, thus causing multiple dispatch processes and therefore multiple rows in your database.

I have checked that all the links on this very simple example page do actually resolve to the resource to which they point.

The session handler is setup as follows:

Zend_Db_Table_Abstract::setDefaultAdapter($db);
Zend_Session::setSaveHandler(new 
            Zend_Session_SaveHandler_DbTable($config->session->toArray()));

The db logging is setup as follows:

$writer = new Zend_Log_Writer_Db($db, $config->log->tableName, 
            $config->log->columnMap->toArray());
$logger = new Zend_Log($writer);

Both objects are correctly setup and can read and write to and from the database. Only everything happens twice. If I put a test log message anywhere in the application it is written into the database twice. If I increment three variables with every call to the index action - one stored in the session, one passed around via a Zend_Registry object and another local to the indexAction - only the session variable is incremented by 2. The Apache access log shows the correct amount of requests being fired from the page load and all have good response codes of either 200 or 304 (unchanged).

I have tried disabling all head links.
I have tried disabling the layout entirely.
I have localised everything to the dispatcher and exited before dispatch is run.

In all cases the extra write/increment takes place.
Any thoughts?
Thanks in advance for any help.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

时光与爱终年不遇 2024-10-23 01:27:38

我似乎已经发现并解决了这个问题。 Chrome(可能还有所有 Webkit 浏览器)在 GET 之上发出额外的 HEAD 请求,这意味着应用程序会被命中两次,并且两次请求都会触发任何基于会话的内容。我的临时解决方案是将以下代码放在我的 index.php 文件的开头附近。

if ("HEAD" == $_SERVER['REQUEST_METHOD']) {
    exit;
}

我希望这可以帮助任何遇到同样问题的人。

I seem to have found and fixed the issue. Chrome (and possibly all Webkit browsers) issues an additional HEAD request on top of the GET which means the application is hit twice and anything session based will be triggered as a result of both requests. My temporary solution is to put the following code near the start of my index.php file.

if ("HEAD" == $_SERVER['REQUEST_METHOD']) {
    exit;
}

I hope that helps anyone with the same issue.

情话已封尘 2024-10-23 01:27:38

Google Chrome 总是通过向服务器发出烦人的请求来请求 favicon.ico。在 Chrome 中请注意这一点。

有关更多信息:

http://framework.zend.com/issues/browse/ZF-11502?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#issue-tabs

感谢塞巴斯蒂安·加伦斯基的贡献。

Google Chrome always asks for the favicon.ico by making annoying requests to the server. Take care about this in Chrome.

For more information:

http://framework.zend.com/issues/browse/ZF-11502?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#issue-tabs

Thanks to the Sebastian Galenski contribution.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文