[PHP-DEV] Timeout Function:
Personally, I think having an alarm (timeout) function is a really good idea. Setting a timer, and then being able to jump from whatever you are doing if it is taking too long is something that has helped me do some really neat stuff in C and Perl... and I was a little dissapointed when I learned PHP didn't have. Of course, I have no idea how hard it would be to do... so my opinion isn't worth a hole lot more than .02 Brian Tanner http://www.zaam.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Manual Error
Maybe its just me, but the section to do with objects, more specifically the :: page is labelled: http://www.php.net/manual/en/keyword.paamayim_nekudotayim.php Is that how it should be? -Tanner -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Bug #11075: bad operation of nl2br function
Ok, I've seen this bug reported too many times to sit idly by. :) The br / has the / so that the html is XHTML compliant. (if memory serves) My question -- is this breaking anything for anyone? Is br / in any way detrimental to browsers anywhere? Brian Tanner Project Manager Zaam Internet Solutions -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Register_Shutdown_Function happens before shutdown
In theory (at least IMHO), this function should be used to register functions to finish up after the client has detached from the server. This way, time consuming tasks like logging, closing connections, sending e-mail, or whatever can be done *after* the client is happily surfing to their next page. However, I have tested Register_Shutdown_Function as much as I can locally, and no matter what I try... I have to wait until my shutdown functions are done before I see the page, get redirected, or whatever. This is bug or a feature? Or am I a dummy? -Brian Tanner -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Bug #11512: Parsing of vars inside a string
I think the problem here is that $varone_foo is the valid form of a variable so: $vartwo=$varone_foo; is getting parsed as a single variable called $varone_foo PHP is *smart* enough to know that foo_$varone is not a valid name for a variable or constant, and it goes out of its way to implicitly treat it like: $vartwo=foo_.$varone instead of $vartwo=foo_$varone; You mentioned that in your example, $vartwo is not blah_foo as expected... if you cranked your error reporting, you'll probably get an error like $varone_foo is not a valid variable -Brian Tanner $varone=blah; $vartwo=$varone_foo; = The resulting contents of $vartwo is not blah_foo as expected. You can only get the desired result by having $vartwo= $varone . _foo; However something like $vartwo=foo_$varone works as expected = foo_blah; Is this a language construct issue perhaps? -- Edit Bug report at: http://bugs.php.net/?id=11512edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Register_Shutdown_Function happens before shutdown
//You must have some bad HTML design however if you can not see your page until after all that is done. Thanks for your insight. You are very wise. //PHP lives inside the connection and content delivery area of Apache. //Therefore, all code is parsed while the connection is open. I'm not talking about the code being parsed, I'm talking about it being executed. However, form your other comment, I am going to assume that you meant executed, and you are trying to tell me that code cannot execute after the connection is severed. This function must be a part of my imagination then: int ignore_user_abort ([int setting]) Also, it seems pretty useless that ShutDown functions can't output to the browser... if it is guaranteed to be hanging around anyway. Why is that? -Brian Tanner Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Brian Tanner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 18, 2001 8:15 PM Subject: [PHP-DEV] Register_Shutdown_Function happens before shutdown In theory (at least IMHO), this function should be used to register functions to finish up after the client has detached from the server. This way, time consuming tasks like logging, closing connections, sending e-mail, or whatever can be done *after* the client is happily surfing to their next page. However, I have tested Register_Shutdown_Function as much as I can locally, and no matter what I try... I have to wait until my shutdown functions are done before I see the page, get redirected, or whatever. This is bug or a feature? Or am I a dummy? -Brian Tanner -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Cookie Detection
//When browser turnoff cookie support, the PHP will add session id at end of all local URL links Can someone put me up to date on exactly *HOW* PHP knows if cookies are enabled? Is there a practical way to check for that? I have my own session handling implemented... and I do both sid passing as well as cookies... but I'd love to know how to detect -Brian Tanner -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Totally Blue Sky
Sounds like a great idea. You could probably improve it by not using an actual browser, but by using the browser properties in a standalone application. Here me out... I am confident there are some Windows widgets that let you easily build you own browser.. which is actually Internet Explorer without all of the options. If you were to make a more limited browser interface (so that you cut out the browser functionality that an application shouldn't have home,forward,back,view source, disable javascript,disable cookies,etc, etc, etc), and then install the browser application... you could probably make it a standardized .EXE so that any user written PHP program would run on it. Other than that, you just need to get the web server figured out. How hard would it be to customize this browser application to start and quit apache in tandem with the application. Again, agree on a standardized apache config so that there is only one site running... which is on local host, you're pretty much set. I think its a great idea. Brian Tanner Project Manager Zaam Internet Solutions Toll Free: 1-866-225-2675 [EMAIL PROTECTED] http://www.zaam.com Situation: PHP is the greatest damned language I've ever used. With PHP and a database on the back-end, and a decent browser capable of running Javascript/JScript on the front end, you can create beautiful, seamless web applications with so little work that it almost seems like cheating. Problem: If you don't want your application to be just a web application, then you're stuck using some other relatively stinky language. Shudders while thinking back to the days when you had to write thousands of lines of code just to put some graphics on the screen or open a socket to a web server Variation on a theme: I'd love to be able to create a PHP Windows .exe that installed just like a regular application. This ideal program would run just like an application too. You'd launch it and it would open an application window, but the window contents would be the current web browser installed on the system, pointed to the index.php page in your newly installed application's directory. In other words, it would be like installing a PHP-enabled webserver whose output could only go to the application's main and child windows (if any). I do NOT want to require the user to install a webserver and I do NOT want the server to keep running after the application has quit, but I would LOVE to be able to do basic application type actions like saving files without having to resort to lame, bloated, miscarriages like signed Java applets. Also, I would LOVE to be able to simply create user interfaces without writing tons of code like in Visual C++. Admittedly, Visual BASIC is similar in purpose here, but as we all know, VB ain't got nothin' on PHP. Questions: [1] Does such a beast exist? [2] Can anyone think of a fundamental reason why we couldn't do such a thing? [3] Is the general consensus that this would be a handy thing to have, or is it just me? Please be kind with the flames, I'm new here... Gre7g. = Gre7g Luterman [EMAIL PROTECTED] http://www.templeofluna.com/ Stay informed: http://www.templeofluna.com/keeper/mailinglist.htm I want to die peacefully in my sleep, like my grandfather ...not screaming in terror like his passengers. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
I want to chime in here. The reason (IMHO) that they are asking you to test the latest release is because you are reporting a symptom of a bigger problem. They *think* that they fixed the bigger problem. However, the best way to be *sure* (like you want) -- is to have people see if the symptoms are gone. Instead of recreating every problem that people describe... they try to fix the root cause, and see if all of the related problems go away. Make sense? -Brian Amazing. No report has been made that the bug has been resolved, yet you have a burr up your butt to close out the problem anyway. Great debugging technique. Truly professional. Good to know PHP is in such good hands. Yes, to answer your comment, I DO remember that I wrote that. In fact, it's basically a repeat of the same thing I wrote earlier, since you did not seem to pay attention the first time. Each time a point release is out, I check it, as I--like many PHP users--would like to have the latest features and bug fixes. PHP totally kicks ass, but unfortunately there are some glitches from time to time. HOWEVER, a nightly CVS build is not considered by most to be a stable release. Ergo we have such things as RELEASE CANDIDATES. PHP is now at 4.0.6 RC3 if memory recalls correctly. However, this too is not a full release. RCs are basically like beta releases for those so inclined (and with sufficient time) to be guinea pigs. CVS nightly builds are for those normally heavily involved, RCs are for those who want to help point out flaws in the next release, and then actual point releases are what most users obtain. I apologize if I don't satisfy your sudden demand for people to jump at testing your nightly builds or RCs. But like many I actually have a job and life that requires most of my time. I gladly test full point releases, but unfortunately do not have time to be your daily minion. This is the first time I've witnessed anyone involved with PHP development act in such a manner. I hope it's not a sign of things to come. Previous Comments: --- [2001-06-19 16:45:30] [EMAIL PROTECTED] Do you remember this: I have not tried the latest snapshots. I tend to wait for point releases to re test. Unfortunately I do not have that much time to keep retesting with the nightly b uilds, etc. When 4.0.6 is released, I will test with that. Then reopen this report when it is not fixed in 4.0.6. period --- [2001-06-19 10:56:24] [EMAIL PROTECTED] What is this, the Microsoft approach to dealing with bugs? You have no evidence if the problem is resolved, yet you close out the problem anyway. Burying your head in the sand doesn't make the issue go away. I'm sorry, but you don't close a problem until a resolution is found and the fix confirmed. There is a session bug, which existed in early 4.0 releases, was then fixed, and is now broken again. The last working version of PHP for Windows that did sessions properly was 4.0.3pl1, and nothing thus far indicates that this issue has been resolved since then. I have updated the PHP Version for you to reflect the problem still exists in 4.0.5, the latest release most users would touch. Most PHP users are not about to touch nightly CVS builds. That's why you HAVE point releases like 4.0.3pl1, 4.0.4, 4.0.5, etc. This problem should remain open until it can be confirmed that the bug is fixed. --- [2001-06-19 09:27:34] [EMAIL PROTECTED] Reopen this if it doesn't work with 4.0.6. --Jani --- [2001-06-15 11:08:43] [EMAIL PROTECTED] I have not tried the latest snapshots. I tend to wait for point releases to retest. Unfortunately I do not have that much time to keep retesting with the nightly builds, etc. When 4.0.6 is released, I will test with that. --- [2001-06-14 23:18:19] [EMAIL PROTECTED] Does this happen with latest snapshot from http://www.zend.com/snapshots/ ?? There have been some fixes regarding this. --Jani --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=8989 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Totally Blue Sky
GTK is actually a GUI and is not based on HTML at all... I think what Greg is looking for is an HTML based application that runs standalone... -Brian Have you looked at http://gtk.php.net/? Maybe that's what you need. Edin - Original Message - From: Gre7g Luterman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 19, 2001 9:43 PM Subject: [PHP-DEV] Totally Blue Sky Situation: PHP is the greatest damned language I've ever used. With PHP and a database on the back-end, and a decent browser capable of running Javascript/JScript on the front end, you can create beautiful, seamless web applications with so little work that it almost seems like cheating. Problem: If you don't want your application to be just a web application, then you're stuck using some other relatively stinky language. Shudders while thinking back to the days when you had to write thousands of lines of code just to put some graphics on the screen or open a socket to a web server Variation on a theme: I'd love to be able to create a PHP Windows .exe that installed just like a regular application. This ideal program would run just like an application too. You'd launch it and it would open an application window, but the window contents would be the current web browser installed on the system, pointed to the index.php page in your newly installed application's directory. In other words, it would be like installing a PHP-enabled webserver whose output could only go to the application's main and child windows (if any). I do NOT want to require the user to install a webserver and I do NOT want the server to keep running after the application has quit, but I would LOVE to be able to do basic application type actions like saving files without having to resort to lame, bloated, miscarriages like signed Java applets. Also, I would LOVE to be able to simply create user interfaces without writing tons of code like in Visual C++. Admittedly, Visual BASIC is similar in purpose here, but as we all know, VB ain't got nothin' on PHP. Questions: [1] Does such a beast exist? [2] Can anyone think of a fundamental reason why we couldn't do such a thing? [3] Is the general consensus that this would be a handy thing to have, or is it just me? Please be kind with the flames, I'm new here... Gre7g. = Gre7g Luterman [EMAIL PROTECTED] http://www.templeofluna.com/ Stay informed: http://www.templeofluna.com/keeper/mailinglist.htm I want to die peacefully in my sleep, like my grandfather ...not screaming in terror like his passengers. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Internal Working -- performance question
I'm am writing a large web application, and on every request, my pages must
load the environment, which takes up a significant amount of time (.1
seconds on a Athlon 1 Ghz).
Much of that time seems to be spent on loading the environment from disk,
and processing it into usable form.
So I thought of running a PHP script all the time, that accepts socket
connections, transfers all the data in serialized form through a port to the
requesting script. The PHP script that is always on would only have to load
the data files once.
Sounds great right... but it actually is slower to transfer data through a
TCP/IP connection from 2 ports on the same machine, if you are doing it with
small chunks (100 Kbytes at a time) -- but I noticed if I cranked the chunk
size, it was up to 100 times faster:
while ($out=socket_read ($sock,10)) {
$EncodedString.=$out;
}
Now, what I am wondering is:
a) Is there a faster way to send data between 2 processes, that will work
with PHP, and is supported by Windows and *nix.
b) Is there any drawback to use data chunks that are: 10 bytes?
I'd ask this on the other list, but nobody is going to really have a good of
a handle as you guys.
-Thanks in advance, sorry for the intrustion.
-Brian Tanner
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Internal Working -- performance question
Thats what I'm looking at doing actually... I would really love to have shared mem in Windows... cause thats what I develop with :( But yah... looking at the 3 pronged approach, falling back to slower and slower implementations. Should make things fast in a good environment at least :) Thanks. -Brian -Original Message- From: James Moore [mailto:[EMAIL PROTECTED]] Sent: June 23, 2001 3:04 AM To: 'Brian Tanner'; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] Internal Working -- performance question a) Is there a faster way to send data between 2 processes, that will work with PHP, and is supported by Windows and *nix. How about abstacting it, under Linux use shared mem (should be fastest) if its avalible, other wise use sockets then If that's not avalible use database/file version. - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Read a file into a string (RE: [PHP-DEV] Sablotron leaks)
Doesn't this do that? $FilePointer=fopen($FileLocation,r); $_MyString.=fread($FilePointer,filesize ($FileLocation)); fclose($FilePointer); Althought I guess this could suck memory pretty hard on large files, and you guys want to get away from that... -Brian Blah... I see this a lot. We should probably just relent and make a function that reads an entire file into a string. Yes, please do :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] About ext/sockets/
Just thought I'd pipe up on this topic, cause its very applicable. I'm a 4th year Honours CompSci student. I've written some client server stuff in C (hence a little sockets experience), and I have been using PHP for a year now. My *only* complaint of PHP is that all the really fun stuff (memory sharing, sockets, couple of others) doesn't work for Windows. I've coded sockets for *nix in C before, but I am rusty. It took me 30 minutes to get familiar and start coding with the new API. The changes are are very straightforward, and make the socket extension work more like the rest of PHP. Returning 0 for success and negative numbers just isn't how PHP does things. http://introverted.com/php-sockets.html Considering a very low % of PHP programmers have extensive C socket experience, I wouldn't worry too much about making it inconvenient. You guys are just a little biased (IMHO), because you are all talented, experienced, C programmers. Anyway.. basically just wanted to say that I have used the new API, it works well, and I was very happy to see sockets making it to windows. -Brian Tanner -Original Message- From: Sascha Schumann [mailto:[EMAIL PROTECTED]] Sent: June 24, 2001 2:19 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] About ext/sockets/ Jeroen, For lower-scale and home-use you can argue it is easier than *nix. So when possible, you should try to support windows. [..] [looked like C, was easier for ppl with C-background] I don't think you should target php at C-ppl. PHP has been since its inception strongly influenced by C. And as a tool originally conceived on Unix, it should maintain its roots and continue to provide people familiar with Unix APIs a convenient way for scripting. Thus, improved Windows support should not come at the expense of Unix support without a perfect reason. I'm missing that reason here. I haven't looked deeply at what API changes have been introduced lately, but I'd suggest to use the standard BSD sockets return value semantics (-1 for failure, = 0 for success). Those semantics also prevail in the Winsock implementation, so they should be quite natural. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Totally Blue Sky
I'm not sure you would be able to distribute a commercial application that is built around PHP commercially, could you? Isn't that what the GPL protects against? -Brian -Original Message- From: Marc Boeren [mailto:[EMAIL PROTECTED]] Sent: June 25, 2001 12:56 AM To: 'Gre7g Luterman'; '[EMAIL PROTECTED]' Subject: RE: [PHP-DEV] Totally Blue Sky I am pleased to announce that I dove into this new idea last night and made my first proof-of-concept program (PoC-1) for this new programming environment (which I am calling LocalPHP for the lack of a better name, any suggestions?). I have a version of exactly what you wish to do right here in the final stages of development. It includes an executable that contains the htmlview, a dll that catches all requests from the htmlview and processes them (either by passing them on to php and passing the results back to the browser, or by returning the requested file as-is). It doesn't need Apache or anything, just the cgi-version of php (including any modules you wish to use), and an IE4. It could easily be extended to fetch all files from one big library (thus protecting your php-source) or to start other apps as well (map any extension to any executable... Perl, custom executables, whatever) We're still looking into the method of distribution, whether it will be a commercial app or an open source project and such things, but your efforts might kick a few people over here into motion :-) As you can understand, I can not really say more about this project at this time, but I'll hope to come back to this soon! Cheerio, MArc. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Scratch That about Arg_Separator
Found it.. sorry to bug you all. -Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] BUG -- (manual send -- the Bug mail send failed)
From: [EMAIL PROTECTED] Operating system: Win32 (Win 2k) PHP version: 4.0.6 PHP Bug Type: Scripting Engine problem Bug description: Unserialize dies with Apache Module but is FINE with CGI I've been running fine on CGI for a while now, jumping between 4.04, 4.07-dev, 4.05 When I tried to switch from 4.05 CGI to 4.05 4.05-Apache ... one of my files does not unserialize properly. The error message is: Warning: unserialize() failed at offset 487 of 2797 bytes in c:\program files\apache group\apache\htdocs\gt2\libraries\classes\module.class on line 189 If you guys know something about this, please let me know, as soon as possible. In the mean time, I am going to make a script that saves a serialized object to disk. I will save it to a file using CGI and then Apache modules. Then, I will try to load em both using Apache and CGI modules... see what turns up. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
-1 ;) I think it could make thing much more difficult and confusing actually. I like to keep all my include files in a central place, and define a constant __IncPath, where __IncPath is something like: $Document_Root.libraries/ That way I always just: include(__IncPath.foo.php); include(__IncPath.bar.php); I guess this might not be the best in all situations, but I find it makes my code more portable. Define one constant, and all is well. Although for newer users, you guys are probably very right. Makes things much easier when learning. So I guess as long as it doesn't add to ambiguity (would there be include_relative() or include($FilePath[,boolean relative])... could be useful. -Brian Tanner -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: July 8, 2001 9:15 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Bug #11961: \r\n or \n
For the record, this is probably the EXACT same problem that was dismissed when I couldn't unserialize objects WRITTEN in CGI mode (non binary) with both Apache Module and CGI version. If I wrote the file with line breaks, with CGI -- the Apache module version of PHP would die on the unserialize, but a CGI version unserialize worked fine... I got told to always write in binary mode, and that the inconsistency when reading was not important. :( Win32, btw -Brian Tanner -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: July 8, 2001 3:46 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug #11961: \r\n or \n From: [EMAIL PROTECTED] Operating system: Win98 SE PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: \r\n or \n I've submitted this bug some days before but I didn't get very kind reply. I decided to resubmit it. test.php: ?php $fp = fopen(test.txt, r); $str = ; while (!feof($fp)) $str .= fgets($fp, 64); fclose($fp); echo count(split(\n, $str)).br /.count(split(\r\n, $str)); ? And I've put 3 random lines in test.txt OK, my PHP is running as Apache module, so when I type localhost/test.php, I got the output 3br /1. Then, I run this script in CGI mode. This can be done simply by the command c:\php_path\php.exe test.php, and I will get the output 3br /3. OK, so PHP is not portable, even in the same platform but different PHP running mode. CGI PHP and module PHP interpret \r\n differently. -- Edit bug report at: http://bugs.php.net/?id=11961edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
Just want to pipe up and say I'm worried about a potential performance hit here. I'm building an enterprise web app that includes over 30 files on every request. Will changing the directory for the include file, and changing it back after create a significant performance hit? (I would think so). Just to point out -- things might get a little more confusing here... because if people get to pretend that the file they are including is being executed in the directory where it is stored, they may have problems adjusting to the idea of making links and images (in HTML) relative to the script that called their file, and they might have to end up re-implementing existing workarounds anyway. Just a thought. -Brian Tanner -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: July 9, 2001 5:48 AM To: Andi Gutmans Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Yeah, this has been requested several times. I think that changing the cwd to the directory of an included file makes good sense. It is, indeed, downwards incompatible and may break existing applications. We have 4 options: 1. Do nothing 2. Make include() and friends change directory to the directory of the file they include. This makes the most sense, but may break existing apps. 3. #2, only make it optional 4. Add the directory of the included file to the include_path when the included file is being executed. It can get a bit nasty with nested includes, even though I think it should work. It's also a bit tricky to implement, as the engine doesn't know about include_path (at least right now). I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. Zeev At 18:14 8/7/2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security Issues
I'm gonna have to go ahead and agree with Peter. As a relative Newbie to PHP (1 year), I can tell you that when I switched from Perl to PHP, one of the biggest Wow, this is great features was the easy variable access. It makes it fast for a newbie to hack something together that works -- which is often all that is really needed. Should the average script be coded better? Yes. However, you can't legislate good coding by imposing sanctions on technique. (IMHO) I agree with Peter that if someone is writing a script with security even in the back corner of their mind, they will be initializing variables, and grabbing them from the appropriate HTTP_*_VARS. If someone has no clue about security, they are lost anyway. You can't *force* their script to be secure from the outside. More likely, they are a novice programmer and will give up on PHP just as they have on Perl -- because it is just too difficult for them to learn. My .02 -Brian Tanner this is not a language issue, it is a script-coder one, if someone is not able to handle this, he is not able to write scripts if register_globals is turned off too - Peter -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Bug #12381: Data Structure Dumper Feature Needed
Actually its a great enough idea that its already there ;) http://www.php.net/manual/en/function.serialize.php Internal Format XML Variant if you want to communicate between apps http://www.php.net/manual/en/ref.wddx.php :) I think thats what you are looking for Brian Tanner Project Manager Zaam Internet Solutions Toll Free: 1-866-225-2675 [EMAIL PROTECTED] http://www.zaam.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: July 25, 2001 3:31 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug #12381: Data Structure Dumper Feature Needed From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: Feature/Change Request Bug description: Data Structure Dumper Feature Needed I'd like to suggest that a built in function for dumping PHP data structures (arrays, variables, etc.) into a string which could then be exported to a file be created. This would work something like the Perl Data::Dumper module. This would be extremely useful for creation of persistent datastructures, especially helpful for programs which include web interfaces to edit settings which are used by another portion of the program. I find myself writing simple code to do this a lot, but it is something that gets pretty messy whenever I'm trying to recreate multidimensional arrays and such so that they can later be required into a PHP page. I'm sure that a function of this type would be useful to a lot of PHP users and I hope you'll consider adding it. I've looked at a lot of the code repository sites by the way, and I haven't found anything that seems to resemble what I'm looking for already available, but I think it's the type of thing that should really be a part of the base PHP. -- Edit bug report at: http://bugs.php.net/?id=12381edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security Issues
accept_parameters($user_string); // or something similar If PHP is going to break a bunch of scripts, they would probably just shut register_globals off. This would require people to do: $user_string=$HTTP_POST_VARS[user_string]; This accomplishes the same thing as your example, and doesn't introduce any new syntax... I don't really see the advantage of the accept_parameters idea. -Brian Tanner -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security Issues
Is all of this springing from that security advisory that was published a
short while ago?
I remember reading that, and feeling that many of the issues were overblown
(if I'm thinking of the same one).
Also, wasn't that advisory just written by some guy? Its not like W3C is
writing a web security standards document and made an example out of PHP or
something, its just the security suggestions/opinions of some guy.
Seems like a whole lot of trouble (breaking thousands of scripts) -- just to
appease some document by some guy.
Also, about this whole car with no brakes or gun aimed at the head
business. I like the car analogy... and the register_globals=off.
See.. turning register_globals off is like adding a huge brake, and then
hiding the accelerator. For beginner drivers, or existing drivers that are
not up on current events, it will be very hard to get going.
I'd say that leaving register_globals on is *exactly* like a regular car.
Its dangerous, hell yeah. However, as long as you learn how to use it in an
enclosed environment, and practice the safety techniques -- you are not too
much of a danger to others when you get onto the highway.
Same concept applies... if you take a beginner and put them on an enterprise
server writing code that manipulates a DNS file or does updates and deletes
to a crucial database, you are asking for trouble.
Thats why people write simple, inconsequential application as they are
*learning*, and after that have some experience, they should write things
where they can actually hurt someone.
Anyway, thats my .02. I'm done talking about this issue... its a difference
of opinion, which is generally very hard to resolve -- and no amount of
logical dicussion can change the mind of either group.
-Brian T
-Original Message-
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
Sent: July 25, 2001 6:29 PM
To: Rasmus Lerdorf
Cc: Andy; [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Security Issues
At 07:31 25/07/2001, Rasmus Lerdorf wrote:
Because not everyone agrees that this is actually highly recommended.
Most third-party PHP code you may want to run will not work very well with
register_globals off. And turning register_globals off isn't actually as
helpful from a security perspective as many people seem to think.
The basic thing it would help would be in cases like this:
?
if($user=='rasmus') {
$ok = true;
}
if($ok) {
... secure code ...
}
?
Here if someone injected ?ok=1 in the URL then the secure code part would
be run regardless of the $user setting. Obviously the fix here is to make
sure that $ok is initialized to false at the top of the script. But since
many people forget to do that, turning off register_globals fixes the
problem.
I tend to agree with the advisory, in the sense that register_globals=on
encourages insecure code, and it would in fact help to disable it by
default. It's true that some (many) people don't understand that they
shouldn't 'trust' any data coming from POST or cookies anymore than they
should trust GET (well, in practice - slightly more, as it takes slightly
more advanced users to work around POST or cookies, than it does to add GET
variables to the URL). However, *lots* of pieces of code, probably even
most of them, are vulnerable to logic bugs because of register_globals set
to on, bugs that would have otherwise not exist. Bugs which occur due to
misunderstanding the 'reliability' of the form data sources are (much) more
rare, and usually, if not always, involve basic misunderstanding of the Web
environment. Security issues that are a result of register_globals=on
often occur even when the user is knowledgeable, and tries to avoid
security bugs. The WTF factor there is pretty high.
The change I would rather see in php.ini would be to have the default
error_level be set to E_ALL because then the above script would generate a
warning complaining about the fact that $ok was not initialized. Since
PHP can determine when variables are not initialized the case for
turning register_globals off in this example is rather weak.
PHP does not require or even encourage initialization of variables -
setting $ok to 1, and then checking it with empty() is considered 'clean'
code, but it'd be equally insecure.
Many people also seem to think that it is somehow more secure if you know
exactly where data is coming from. So that if you use
$HTTP_POST_VARS['var'] then somehow $var is not spoofable because if you
put ?var=foo in the URL it won't affect anything. But injecting variables
into POST or Cookie data is trivial so I don't see this argument holding
much water either.
As I said, it's easy, but it is considerably less easy than it is to add
GET variables. Let alone the fact that we're also dealing with SERVER and
ENV vars, which cannot be injected at all. How about people who check
server variables, such as HTTPS, using isset()? register_globals *is*
RE: [PHP-DEV] Security Issues
Thanks for the cool response Zeev.. I was a little agitated when I wrote that letter, glad you didn't take it the wrong way. Again, my position is very simple. I agree that what you are suggesting would greatly reduce the exploits of the language. Just concerned about the cost, and if the benefit/cost ratio is in the right ballpark. I think it might be too much of a cost, for not enough benefit. I personally feel that these issues up to the programmer, (hence the difference of opinion). This change will break many of my scripts, some of which can take variables from Get, Post, or Cookies. I'm not looking forward to writing the logic to *fix* all of these, when my scripts are secure as it stands now. You asked if I examined my scripts, could they be caused to behave differently if someone knew the source? Differently - sometimes Dangerously - Never And my apps are not exactly hit counters either. I'm actually working on a very large project that I'm going to tell you all about one day soon, when its done ;) -Brian T -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: July 27, 2001 10:06 AM To: Brian Tanner Cc: [EMAIL PROTECTED] Subject: RE: [PHP-DEV] Security Issues At 10:19 27/07/2001, Brian Tanner wrote: Is all of this springing from that security advisory that was published a short while ago? I remember reading that, and feeling that many of the issues were overblown (if I'm thinking of the same one). Also, wasn't that advisory just written by some guy? Its not like W3C is writing a web security standards document and made an example out of PHP or something, its just the security suggestions/opinions of some guy. Seems like a whole lot of trouble (breaking thousands of scripts) -- just to appease some document by some guy. I don't know if that's just one guy or a group of people, but that one guy found exploitable bugs in pretty much any big PHP app he researched. Instead of ignoring his findings and saying he's just one guy, it's best to read the advisory and understand that he's really right about his assessment, that register_globals is the mother of a huge number of security flaws in PHP applications. Also, about this whole car with no brakes or gun aimed at the head business. I like the car analogy... and the register_globals=off. See.. turning register_globals off is like adding a huge brake, and then hiding the accelerator. For beginner drivers, or existing drivers that are not up on current events, it will be very hard to get going. That's simply not true, and it should be clear that it's not true. Teaching people to use $_GET[foo] is not more difficult than teaching them to use $foo. It's also more explicit and clear to read. If we were in front of a blank design board right now, it wouldn't have even be a question. The new method is equally clear, and has some advantages (the only disadvantage being a few more keystrokes, but that's not a big deal). The only reason we're having this debate is due to downwards compatibility. I'd say that leaving register_globals on is *exactly* like a regular car. Its dangerous, hell yeah. However, as long as you learn how to use it in an enclosed environment, and practice the safety techniques -- you are not too much of a danger to others when you get onto the highway. Same concept applies... if you take a beginner and put them on an enterprise server writing code that manipulates a DNS file or does updates and deletes to a crucial database, you are asking for trouble. Thats why people write simple, inconsequential application as they are *learning*, and after that have some experience, they should write things where they can actually hurt someone. Anyway, thats my .02. I'm done talking about this issue... its a difference of opinion, which is generally very hard to resolve -- and no amount of logical dicussion can change the mind of either group. Take a look at your apps, take a close look, and see if they're vulnerable to such attacks. Your apps may not be doing any 'dangerous' stuff, but try to see if a remote user, knowing the source code of the script, could cause your apps to behave differently with the right input. From my experience, many, if not most of the scripts fall into this category. If it's 0.1% of the population making mistakes, it's one thing. If it's 20% or 50%, it means that the language is at flaw. Even if you disagree that the language is at flaw and 'people should be taught how to drive more safely', there's no doubt that decreasing the chances of them making an accident very considerably is a good thing. As I told Peter, we're not talking about liability here, or who's to blame. We're trying to figure out the best way to convey PHP to people, and make them create good PHP applications. Right now, PHP encourages them to write bad apps, which is a bad thing, and gives PHP bad reputation. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe
RE: [PHP-DEV] Security Issues
Brian Foddy actually brings up a really important issue, which would go along way to making (at least me) much happier with the proposed change. *If* there will be: $_Get[] $_Post[] $_Cookie[] -- can we also have something else to the tune of: $_External or $_User or $_Something That gets populated based on the ordering set for GPC right now in the .ini file? I think it would go really far towards helping a newbie (and to helping people fix their existing code), if there was one place that they could look, to find the old value that they are now missing. People can still go to _Get, _Post, and _Cookie if they require that level of granularity, but I think most will be happy with a general container for what Register_Globals *would* have done. -Brian T -Original Message- If I can just interject once, I was a bit skeptical of this thread at first but I'm starting to come around to Zeev's point of view. Security aside (which I know it shouldn't be) I found in my own coding I always started naming post or get variables like $form_user_name or $post_user_name so I could easily tell just by looking at individual sections of the code that this variable was web input, vs my own internal variable. But even still, it can be confusing to newbes trying to understand just how did this variable get its value?. Having the $_GET[ post_user_name] is much more straight forward. But is there a $_POST call also? Making a important distinction between data posted or getted input? If so, that may be a small inconvienence. Good debate tho, and well timed for other issues I'm dealing with. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
FW: [PHP-DEV] Security Issues
Just passing this along form Ramsi... who sent it to me instead of the list. (unless he wants to unsubscribe from my point of view :P )-Original Message-From: Ramsi Sras [mailto:[EMAIL PROTECTED]]UNSUBSCRIBE ME PLEASE!! Brian Tanner schrieb: Brian Foddy actually brings up a really important issue, which would go along way to making (at least me) much happier with the proposed change. *If* there will be: $_Get[] $_Post[] $_Cookie[] -- can we also have something else to the tune of: $_External or $_User or $_Something That gets populated based on the ordering set for GPC right now in the .ini file? I think it would go really far towards helping a newbie (and to helping people fix their existing code), if there was one place that they could look, to find the old value that they are now missing. People can still go to _Get, _Post, and _Cookie if they require that level of granularity, but I think most will be happy with a general container for what Register_Globals *would* have done. -Brian T -Original Message- If I can just interject once, I was a bit skeptical of this thread at first but I'm starting to come around to Zeev's point of view. Security aside (which I know it shouldn't be) I found in my own coding I always started naming post or get variables like $form_user_name or $post_user_name so I could easily tell just by looking at individual sections of the code that this variable was web input, vs my own internal variable. But even still, it can be confusing to newbes trying to understand "just how did this variable get its value?". Having the $_GET[ "post_user_name"] is much more straight forward. But is there a $_POST call also? Making a important distinction between data posted or getted input? If so, that may be a small inconvienence. Good debate tho, and well timed for other issues I'm dealing with. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] HEY RASMI SRAS -- READ THE BOTTOM OF THE MESSAGE
To unsubscribe, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security proposal - SPHP and helper functions
-Original Message-
From: David Wheeler [mailto:[EMAIL PROTECTED]]
Sent: August 6, 2001 8:20 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] Security proposal - SPHP and helper functions
Dear Developers of PHP:
I have a proposal that I hope you'll like that I think will
improve the security of PHP programs.
Shaun Clowes recently posted A Study in Scarlet, identifying
common vulnerabilities in PHP applications; you can see it at:
http://www.securereality.com.au/studyinscarlet.txt
I agree with Rasmus Lerdorf
that several of these issues are present in other scripting languages,
and that a key issue is that you need to check input before depending on it.
However, Clowes makes some very good points too. In particular,
it's not just that PHP makes input easier to get at.
PHP allows attackers to totally control all global variables unless the
Personally, I think that having the functions mentioned in David's post are
a great idea. These options would not only improve security by helping
people work around not having globals registered, but it would also make
data validation much simpler. Currently, I have a bigass form_handler
class -- which validates data, cleans it, etc, etc -- but it would be much
simpler if I had a better way to get/check some things.
-Brian Tanner
//Original Message
function get_input ($variable)
# Return value of input named variable, or if unset.
# This pays attention to gpc_order, and looks at
# $HTTP_COOKIE_VARS, $HTTP_GET_VARS, and $HTTP_POST_VARS
function import_variables ($list_of_variables)
# Take a list of input (field) names as strings, and import any that
exist.
function import_input_ifmatch($pattern, $list_of_variables)
# Take a list of input (field) names as strings, and import any that
exist,
# but only if they match pattern (a Perl5 pattern, see preg_match).
# The pattern wll apply to each variable in its entirety, as though
# the pattern has '\A' prepended and '\z' appended.
function import_input_int($list_of_variables)
# Take a list of input (field) names as strings, and import any that
exist
# as ints.
function import_input_double($list_of_variables)
# Take a list of input (field) names as strings, and import any that
exist
# as ints.
For your abusement, here's an implementation of import_variables:
function import_variables () {
# Take a list of input (field) names as strings, and import any that
exist.
$numargs = func_num_args();
$arg_list = func_get_args();
for ($i = 0; $i $numargs; $i++) {
$v = $arg_list[$i];
global $$v;
$$v = get_input($v);
};
};
In SPHP, programs would generally begin with calls to these import
functions, so that programs would only import values that they wanted
(instead of trusting attackers not to create new variables), e.g.:
import_variables(name, description);
import_input_ifmatch(yes|no, bald);
import_input_int(age);
This is a little different than Zeev Suraski's 2001-07-29 post
(http://marc.theaimsgroup.com/?l=php-devm=99638994225888w=2), because
it leaves the (less secure) mode of running PHP scripts running as-is.
Basically, this has a migration plan.
Someday in the future you might even make register_globals off
for regular PHP -- but this would at least give you a
transition approach. And if you're willing to change PHP to make
register_globals the default, that would be MUCH better from a security
standpoint. Even then, though, I think a set of helper functions to
make it easy to import only the values we expect is important --
developers will only write secure programs if it's easy to do the right
way.
Anyway, I'd like to see future versions of PHP make it easy, not hard,
to write secure programs in. I hope this email helps!
--- David A. Wheeler
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Bug #12965 Updated: fopen() don't open URL files
On the fopen page (of php manual), you'll notice:
Versions prior to PHP 4.0.5 do not handle HTTP redirects. Because of this,
directories must include trailing slashes.
http://www.domain.com is not actually a valid path... apache realizes you
want http://www.domain.com/ and issues a header redirect. fopen cannot
handle the redirect.
-Thought I'd give a shot at a little explanation instead of just suggesting
the /.
-Brian Tanner
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: August 28, 2001 11:25 AM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] Bug #12965 Updated: fopen() don't open URL files
ID: 12965
Updated by: sander
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Filesystem function related
Operating System: Windows2000
PHP Version: 4.0.6
New Comment:
I got a slightly different error:
Warning: fopen(http://www.php.net,r;) - No error in
e:\sander\webserver\http\test\test1.php on line 10
If you append a / to the url, it works:
fopen(http://www.php.net/;, r)
The errors are a bit weird though...
Let's make it a bogus.
Previous Comments:
[2001-08-26 10:45:23] [EMAIL PROTECTED]
I'm using PhP 4.0.6 with Apache 1.3 and the
problem is opening remote files with fopen(http://...;);
The following code:
$fp = fopen(http://www.php.net;, r) or die(OPEN);
while (! feof($fp))
{
fread($fp, 1024) or die(READ);
}
fclose($fp) or die(CLOSE);
Produced the following output:
Warning: php_hostconnect: connect failed in filename.php..
Warning: fopen(http://www.php.net,r;) - Bad file
descriptor in filename.php..
I tried to use fsockopen() with my IE proxy and port settings - it was
successful. Maybe the problem is in Apache configuration, but I just can't
figure that out!
If you can help, please, send to my email: [EMAIL PROTECTED]
Kind regards
Edit this bug report at http://bugs.php.net/?id=12965edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
