以编程方式请求的页面中的会话
在对这个问题进行了一些研究之后，我找不到任何令人满意的解决方案。
问题是： 我正在以编程方式执行 GET 请求。请求本身工作正常，请求的页面也工作正常。在请求的页面中执行任何其他操作之前，我需要检查登录是否有效，因此我发送了会话 cookie 来接收会话的 ID，这也可以正常工作。但是当我调用 *session_start( )* 时，请求就超出了 60 秒的执行时间限制。不过，直接访问请求的页面效果很好。
这可能是一个重要的评论： 请求页面也使用会话进行相同的检查。
我希望请求的页面是“远程”/“独立”/无论您如何称呼它的原因是我也想让它可以通过 AJAX 访问。我想简单地包含该文件并检查该文件是否被直接调用也可以，但我现在已经这样做了，并且对此几乎满意。
我现在的问题是：有人能告诉我为什么 session_start 会让我的脚本崩溃吗？有人知道这个的补丁吗？
After doing some research on this issue, I couldn't find any satisfying fix.
The problem is:
I'm performing a GET request programmatically. The request itself works fine and the requested page does so as well. I need to check for a valid login before performing any other actions within the requested page, therefore I've sent the Session cookie to receive the Session's ID, which also works fine. But as soon as I invoke *session_start( )*, the request exceeds the execution time limit of 60 seconds. Accessing the requested page directly works fine, though.
This might be an important remark:
The requesting page also uses Sessions for the same checkings.
The reason why I want the requested page to be "remote" / "standalone" / however you want to call it, is that I want to make it accessible via AJAX as well. I suppose simply including the file and check whether the file is directly called would work as well, but I've done it now this way and am almost satisfied with it.
My question now is: Can anybody tell me why session_start rather crashes my script? And does somebody know a patch for this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
PHP 中的会话是阻塞的，这意味着如果您在同一主机上运行使用同一会话的两个请求，其中一个请求将被阻塞（等待），直到第一个请求完成。
在您的情况下，如果您的编程 GET 请求使用客户端的会话 ID，则两个脚本可能会相互阻塞 - 并且因为一个脚本正在调用另一个脚本，所以“子”脚本将无限期地等待。
在不了解您的项目的情况下很难提出解决方案，但我觉得使用客户端的会话 ID 发出编程式 GET 请求是不对的。也许你可以改变这种行为。
Sessions are blocking in PHP, meaning that if you run two requests on the same host that use the same session, one of them will be blocked (waiting) until the first one has finished.
In your situation, if your programmatic GET request uses the client's session ID, it could be that the two scripts are blocking each other - and because the one is calling the other, the "child" script will wait indefinitely.
It's hard to suggest a solution without knowing your project, but it feels to me it isn't right to make a programmatic GET request with the client's session ID. Maybe you can change that behaviour.