ID: 28856 User updated by: pubnelle at megaphone dot ch Reported By: pubnelle at megaphone dot ch Status: Bogus Bug Type: Session related Operating System: Mac OS X server 10.3.4 PHP Version: 4.3.6 New Comment:
I thought better of PHP than this behavior, pages hanging and slowing down the server because of something that is not documented. Where is it written than you have to close the session before including a distant page using the same temporary folder for session files ? And what about servers having a lot of virtual hosts but not carefully configured and with one folder for session files of all virtual hosts ? Flagged as bogus, I hope that people having the same problem will find this thread, yet, it will spare them a lot of time. Previous Comments: ------------------------------------------------------------------------ [2004-07-14 14:19:22] [EMAIL PROTECTED] It's not a workaround, it's the right way to do it.. (see bug #22526) ------------------------------------------------------------------------ [2004-06-21 20:32:33] pubnelle at megaphone dot ch Yes, of course, you are right. But to start with, we use the maximum of what php offers us to secure our scripts, so that files that are on our server but not owned by the same user that the one of the current script cannot be accessed, and files that are not in the folder of the virtual host cannot be accessed also. Then, when you need a functionality that is available on this server, but without giving out the configuration of this functionality (passwords to access databases, for example), the way to do it is to access it through http. Evey time that this is possible we avoid the include of http url, of course. But we are extensively using a Content Management System, developed in php, that works great, and that requires those includes to have all in one the correct behavior and the design of the client host. Those includes, once again, are also a protection to scripts that have more rights on databases than we want to give to the virtual host that is including it. By the way, what you do of it is not a problem to me. But the precise information that this problem, that has already be one for other users, occurs exactly because of this session point and precisely when we access it, same session id, twice on the same server, saved in the same session files, but once through an http include, seemed of interest. Sure enough, this could be a security feature, and not a bug - but only if you are aware of it. ;-) ------------------------------------------------------------------------ [2004-06-21 20:15:51] [EMAIL PROTECTED] The suggestion there to use include/require was intended to mean a local include/require not an external one. In a typical Apache setup any files accessible to one virtual host is going to be accessible to another. Not directly via http of course, but PHP's include uses the filesystem so it would be something like: include '/var/www/example.com/file.php'; as opposed to: include 'http://example.com/file.php'; The former is an order of magnitude faster than the latter. ------------------------------------------------------------------------ [2004-06-21 07:52:05] pubnelle at megaphone dot ch That definitely makes sense ! There are plenty of times when you need to include a file that is on the same server ! Here, it is to use a Content Management System, which has more rights on the databases, and which is not directly accessible by our clients. When it is not localhost, it can simply be another virtual host, by the way. We use it often. In the virtual() doc : "As of PHP 4.0.6, you can use virtual() on PHP files. However, it is typically better to use include() or require() if you need to include another PHP file. " It is not precised if this is for http include or local include, that's true. ------------------------------------------------------------------------ [2004-06-20 23:03:09] [EMAIL PROTECTED] Why are you using an http include to localhost? That makes no sense. You have fast direct access to this file already. Just include it directly. If you really need it to act like a completely separate request (which you shouldn't) use a sub-request via virtual(). ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/28856 -- Edit this bug report at http://bugs.php.net/?id=28856&edit=1
