[PHP-DEV] Bug #14310: Uploaded empty files treated differently
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: HTTP related Bug description: Uploaded empty files treated differently When a zero-length file is uploaded, the temporary file is not created, and the appropriate variable is set to 'none'. This forces me into all sorts of hacks in my php code (can't use is_uploaded_file() and move_uploaded_file(), for instance), to give empty files special treatment. I think that *a file is a file*, and its size should not matter, as long as it is within limits. Many thanks, -- Arcady Genkin -- Edit bug report at: http://bugs.php.net/?id=14310edit=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-DEV] Bug #14076 Updated: fopen() and touch() fail to create file under safe mode
ID: 14076 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Directory/Filesystem functions Operating System: Linux PHP Version: 4.0.6 New Comment: Well, the fact that it can create a *new directory* in the same directory, already means that the apache process has sufficient permissions to also create a file in it. However, these are the permissions: webedit@penguin:/var/www/tmp/submit$ ls -lad ./ drwxrwx--- 18 webedit www 4096 Nov 15 19:13 ./ Apache runs as user `www', and the scripts are owned by user `webedit'. Note that the directory is owned by the same user as the script, and writeable to Apache, so the requirements of safe mode are met. Thank you for your response. -- Arcady Genkin Previous Comments: [2001-11-19 12:37:01] [EMAIL PROTECTED] Post please the mod of your directory and tell me the user and group of your apache. Maybe the apache dont have rights to create a new file in your directory but he owns the newfile and can remove/edit this file. [2001-11-15 18:53:16] [EMAIL PROTECTED] Under safe mode, fopen(filename, w) fails to create a file if it doesn't exist, complaining about open_basedir restriction. However, the filename refers to the file in the directory configured in the open_basedir. Besides, if the same file is created manually, fopen() can open it for writing without any problems. The directory is writeable to the web server. $dir = '/var/www/tmp/submit'; // Fails if the file doesn't exist. // Succeeds if the file does exist fopen( $dir/file.txt, w ); // Fails if the file doesn't exist. mkdir( $dir/foo, 0700 ); // SUCCEEDS!!! Notice the same path. Edit this bug report at http://bugs.php.net/?id=14076edit=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-DEV] Bug #14076: fopen() and touch() fail to create file under safe mode
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: *Directory/Filesystem functions Bug description: fopen() and touch() fail to create file under safe mode Under safe mode, fopen(filename, w) fails to create a file if it doesn't exist, complaining about open_basedir restriction. However, the filename refers to the file in the directory configured in the open_basedir. Besides, if the same file is created manually, fopen() can open it for writing without any problems. The directory is writeable to the web server. $dir = '/var/www/tmp/submit'; // Fails if the file doesn't exist. // Succeeds if the file does exist fopen( $dir/file.txt, w ); // Fails if the file doesn't exist. mkdir( $dir/foo, 0700 ); // SUCCEEDS!!! Notice the same path. -- Edit bug report at: http://bugs.php.net/?id=14076edit=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-DEV] Bug #13843 Updated: Command arguments under safe mode should not be automatically escaped
ID: 13843 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Summary: Command line arguments escaped magically and out of control Status: Open Bug Type: Program Execution Operating System: Unix PHP Version: 4.0.6 New Comment: I've looked into this further, and here's the scoop. Under safe mode, php uses php_escape_shell_cmd() function to escape any command passed to program execution functions. As a result, if I pass a command like this: /www/bin/foo bar c 21 it will turn it into /www/bin/foo \bar c\ 2\\1 I, as a PHP developer, have no control over this under safe mode. Among other things, this means that I cannot pass my program an argument, containing spaces, nor can I use shell redirection machinery. I propose a patch like below to inhibit this automatic escaping. diff -rc php-4.0.6-orig/ext/standard/exec.c php-4.0.6/ext/standard/exec.c *** php-4.0.6-orig/ext/standard/exec.c Mon Apr 30 08:43:39 2001 --- php-4.0.6/ext/standard/exec.c Mon Oct 29 15:31:06 2001 *** *** 92,100 *c = ' '; strncat(d, c, overflow_limit); } - tmp = php_escape_shell_cmd(d); - efree(d); - d = tmp; #if PHP_SIGCHILD sig_handler = signal (SIGCHLD, SIG_DFL); #endif --- 92,97 Previous Comments: [2001-10-26 21:29:47] [EMAIL PROTECTED] 4.0.6 (safe mode), Apache 1.3.20, running as server module, under Solaris 8/Sparc When passing arguments to an executable with either exec(), system() or passthru(), special shell characters are escaped automatically, and I have no control over it. As a result, I am unable to pass to the executable a paramter containing white space (such as a file name with spaces), because I cannot surround it with quotes or backslash the spaces (the automatic escaping protects the quotes or backslash from the shell). Another consequence is that I cannot use shell redirection symbols (e.g. 21): they get escaped, too, and the executable receives the string 21 as one of its parameters. If I use escapeshellarg() for each argument (as I should), the single quotes, put arround the argument by that function, are passed over as part of the argument. For example: $arg = escapeshellarg(/var/www/data/foo bar.txt); passthru( /var/www/bin/myprog $arg ); Produces the following output from myprog: '/var/www/data/foo: No such file or directory bar.txt': No such file or directory I suspect that this bug may be specific to Solaris, since I could not reproduce the same behaviour under identical configuration under FreeBSD. Hoping for a fix in the upcoming release, -- Arcady Genkin Edit this bug report at http://bugs.php.net/?id=13843edit=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-DEV] Bug #13843 Updated: Command arguments under safe mode should not be automatically escaped
ID: 13843 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Summary: Command line arguments escaped magically and out of control Status: Open Bug Type: Program Execution Operating System: Unix PHP Version: 4.0.6 New Comment: I forgot to add that it appears that this bug is not Solaris-specific, but, rather, safe mode specific. Previous Comments: [2001-10-29 16:14:31] [EMAIL PROTECTED] Well, not being able to use shell redirection and command line args in safe-mode makes a lot of sense. You could trivially circumvent the safe-mode restrictions if you were allowed to do this. Basically safe-mode only allows system calls to very limited things. Basically prepared scripts placed in the safe-mode-exec-dir. I don't see how we could allow arguments and redirects and still maintain the point behind safe-mode. [2001-10-29 16:09:44] [EMAIL PROTECTED] I've looked into this further, and here's the scoop. Under safe mode, php uses php_escape_shell_cmd() function to escape any command passed to program execution functions. As a result, if I pass a command like this: /www/bin/foo bar c 21 it will turn it into /www/bin/foo \bar c\ 2\\1 I, as a PHP developer, have no control over this under safe mode. Among other things, this means that I cannot pass my program an argument, containing spaces, nor can I use shell redirection machinery. I propose a patch like below to inhibit this automatic escaping. diff -rc php-4.0.6-orig/ext/standard/exec.c php-4.0.6/ext/standard/exec.c *** php-4.0.6-orig/ext/standard/exec.c Mon Apr 30 08:43:39 2001 --- php-4.0.6/ext/standard/exec.c Mon Oct 29 15:31:06 2001 *** *** 92,100 *c = ' '; strncat(d, c, overflow_limit); } - tmp = php_escape_shell_cmd(d); - efree(d); - d = tmp; #if PHP_SIGCHILD sig_handler = signal (SIGCHLD, SIG_DFL); #endif --- 92,97 [2001-10-26 21:29:47] [EMAIL PROTECTED] 4.0.6 (safe mode), Apache 1.3.20, running as server module, under Solaris 8/Sparc When passing arguments to an executable with either exec(), system() or passthru(), special shell characters are escaped automatically, and I have no control over it. As a result, I am unable to pass to the executable a paramter containing white space (such as a file name with spaces), because I cannot surround it with quotes or backslash the spaces (the automatic escaping protects the quotes or backslash from the shell). Another consequence is that I cannot use shell redirection symbols (e.g. 21): they get escaped, too, and the executable receives the string 21 as one of its parameters. If I use escapeshellarg() for each argument (as I should), the single quotes, put arround the argument by that function, are passed over as part of the argument. For example: $arg = escapeshellarg(/var/www/data/foo bar.txt); passthru( /var/www/bin/myprog $arg ); Produces the following output from myprog: '/var/www/data/foo: No such file or directory bar.txt': No such file or directory I suspect that this bug may be specific to Solaris, since I could not reproduce the same behaviour under identical configuration under FreeBSD. Hoping for a fix in the upcoming release, -- Arcady Genkin Edit this bug report at http://bugs.php.net/?id=13843edit=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-DEV] Bug #13843 Updated: Command arguments under safe mode should not be automatically escaped
ID: 13843 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Summary: Command line arguments escaped magically and out of control Status: Open Bug Type: Program Execution Operating System: Unix PHP Version: 4.0.6 New Comment: Rasmus, what you are saying about shell redirection being a threat under safe mode makes sesnse. But how about being able to pass parameters with spaces in them? I cannot see any security implication in that... In any case, I want to be able to read standard error from the command I'm executing... How about providing a PHP variant of C's execv() in PHP, so that I could pass it an array of parameters? And, perhaps, add a flag to existing program execution functions to duplicate standard error to standard in. Previous Comments: [2001-10-29 16:14:34] [EMAIL PROTECTED] I forgot to add that it appears that this bug is not Solaris-specific, but, rather, safe mode specific. [2001-10-29 16:14:31] [EMAIL PROTECTED] Well, not being able to use shell redirection and command line args in safe-mode makes a lot of sense. You could trivially circumvent the safe-mode restrictions if you were allowed to do this. Basically safe-mode only allows system calls to very limited things. Basically prepared scripts placed in the safe-mode-exec-dir. I don't see how we could allow arguments and redirects and still maintain the point behind safe-mode. [2001-10-29 16:09:44] [EMAIL PROTECTED] I've looked into this further, and here's the scoop. Under safe mode, php uses php_escape_shell_cmd() function to escape any command passed to program execution functions. As a result, if I pass a command like this: /www/bin/foo bar c 21 it will turn it into /www/bin/foo \bar c\ 2\\1 I, as a PHP developer, have no control over this under safe mode. Among other things, this means that I cannot pass my program an argument, containing spaces, nor can I use shell redirection machinery. I propose a patch like below to inhibit this automatic escaping. diff -rc php-4.0.6-orig/ext/standard/exec.c php-4.0.6/ext/standard/exec.c *** php-4.0.6-orig/ext/standard/exec.c Mon Apr 30 08:43:39 2001 --- php-4.0.6/ext/standard/exec.c Mon Oct 29 15:31:06 2001 *** *** 92,100 *c = ' '; strncat(d, c, overflow_limit); } - tmp = php_escape_shell_cmd(d); - efree(d); - d = tmp; #if PHP_SIGCHILD sig_handler = signal (SIGCHLD, SIG_DFL); #endif --- 92,97 [2001-10-26 21:29:47] [EMAIL PROTECTED] 4.0.6 (safe mode), Apache 1.3.20, running as server module, under Solaris 8/Sparc When passing arguments to an executable with either exec(), system() or passthru(), special shell characters are escaped automatically, and I have no control over it. As a result, I am unable to pass to the executable a paramter containing white space (such as a file name with spaces), because I cannot surround it with quotes or backslash the spaces (the automatic escaping protects the quotes or backslash from the shell). Another consequence is that I cannot use shell redirection symbols (e.g. 21): they get escaped, too, and the executable receives the string 21 as one of its parameters. If I use escapeshellarg() for each argument (as I should), the single quotes, put arround the argument by that function, are passed over as part of the argument. For example: $arg = escapeshellarg(/var/www/data/foo bar.txt); passthru( /var/www/bin/myprog $arg ); Produces the following output from myprog: '/var/www/data/foo: No such file or directory bar.txt': No such file or directory I suspect that this bug may be specific to Solaris, since I could not reproduce the same behaviour under identical configuration under FreeBSD. Hoping for a fix in the upcoming release, -- Arcady Genkin Edit this bug report at http://bugs.php.net/?id=13843edit=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-DEV] Bug #13843 Updated: Command arguments under safe mode should not be automatically escaped
ID: 13843 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Summary: Command line arguments escaped magically and out of control Status: Open Bug Type: Program Execution Operating System: Unix PHP Version: 4.0.6 New Comment: Rats! I meant to say to standard out in the last sentence. Previous Comments: [2001-10-29 16:23:58] [EMAIL PROTECTED] Rasmus, what you are saying about shell redirection being a threat under safe mode makes sesnse. But how about being able to pass parameters with spaces in them? I cannot see any security implication in that... In any case, I want to be able to read standard error from the command I'm executing... How about providing a PHP variant of C's execv() in PHP, so that I could pass it an array of parameters? And, perhaps, add a flag to existing program execution functions to duplicate standard error to standard in. [2001-10-29 16:14:34] [EMAIL PROTECTED] I forgot to add that it appears that this bug is not Solaris-specific, but, rather, safe mode specific. [2001-10-29 16:14:31] [EMAIL PROTECTED] Well, not being able to use shell redirection and command line args in safe-mode makes a lot of sense. You could trivially circumvent the safe-mode restrictions if you were allowed to do this. Basically safe-mode only allows system calls to very limited things. Basically prepared scripts placed in the safe-mode-exec-dir. I don't see how we could allow arguments and redirects and still maintain the point behind safe-mode. [2001-10-29 16:09:44] [EMAIL PROTECTED] I've looked into this further, and here's the scoop. Under safe mode, php uses php_escape_shell_cmd() function to escape any command passed to program execution functions. As a result, if I pass a command like this: /www/bin/foo bar c 21 it will turn it into /www/bin/foo \bar c\ 2\\1 I, as a PHP developer, have no control over this under safe mode. Among other things, this means that I cannot pass my program an argument, containing spaces, nor can I use shell redirection machinery. I propose a patch like below to inhibit this automatic escaping. diff -rc php-4.0.6-orig/ext/standard/exec.c php-4.0.6/ext/standard/exec.c *** php-4.0.6-orig/ext/standard/exec.c Mon Apr 30 08:43:39 2001 --- php-4.0.6/ext/standard/exec.c Mon Oct 29 15:31:06 2001 *** *** 92,100 *c = ' '; strncat(d, c, overflow_limit); } - tmp = php_escape_shell_cmd(d); - efree(d); - d = tmp; #if PHP_SIGCHILD sig_handler = signal (SIGCHLD, SIG_DFL); #endif --- 92,97 [2001-10-26 21:29:47] [EMAIL PROTECTED] 4.0.6 (safe mode), Apache 1.3.20, running as server module, under Solaris 8/Sparc When passing arguments to an executable with either exec(), system() or passthru(), special shell characters are escaped automatically, and I have no control over it. As a result, I am unable to pass to the executable a paramter containing white space (such as a file name with spaces), because I cannot surround it with quotes or backslash the spaces (the automatic escaping protects the quotes or backslash from the shell). Another consequence is that I cannot use shell redirection symbols (e.g. 21): they get escaped, too, and the executable receives the string 21 as one of its parameters. If I use escapeshellarg() for each argument (as I should), the single quotes, put arround the argument by that function, are passed over as part of the argument. For example: $arg = escapeshellarg(/var/www/data/foo bar.txt); passthru( /var/www/bin/myprog $arg ); Produces the following output from myprog: '/var/www/data/foo: No such file or directory bar.txt': No such file or directory I suspect that this bug may be specific to Solaris, since I could not reproduce the same behaviour under identical configuration under FreeBSD. Hoping for a fix in the upcoming release, -- Arcady Genkin Edit this bug report at http://bugs.php.net/?id=13843edit=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-DEV] Bug #11940 Updated: ill side effect of open_basedir
ID: 11940 User Update by: [EMAIL PROTECTED] Old-Status: Closed Status: Open Old-Bug Type: *General Issues Bug Type: Documentation problem Operating system: Solaris 8/sparc PHP Version: 4.0.6 Description: ill side effect of open_basedir Jason, thanks for the clarification. I apologize for persistence, but I'm re-opening the bug under the different category. There are two issues here now: 1. The documentation does not describe this configuration option clearly. It only talks about (quote) When a script tries to open a file It should mention that the restriction applies to the script itself. The first sentence may imply this, but only very vaguely. http://www.php.net/manual/en/configuration.php 2. The error message logged by PHP is not helpful. It talks about opening file for inclusion, which actually is probably what let into confusion even you when you replied to this bug in the first place. Also, the words Unknown in both sentences of the error message are not very helpful, too. Thanks again, -- Arcady Genkin Previous Comments: --- [2001-07-06 23:26:52] [EMAIL PROTECTED] Sorry, I wrote that in a hurry. ANY file open operation performed by php has to be in open_basedir. ( Including your main script. ) This is actually by design. -Jason --- [2001-07-06 18:25:15] [EMAIL PROTECTED] I may be missing something, but there is no include() or any other file-related operation in the sample script that I posted. All it has is 'echo hello'. --- [2001-07-06 17:43:40] [EMAIL PROTECTED] This is not a bug, include calls a file open operation, and as such must be in the open_basedir path -Jason --- [2001-07-06 17:36:45] [EMAIL PROTECTED] safe_mode = On doc_root = /homes/u0/apache open_basedir = /var/www/htdocs/workathome:/var/www/secure:/var/www/tmp (/var/www is a symlink for /homes/u0/apache) In such a setting I should be able to execute PHP scripts from any directory under /homes/u0/apache, but not access any files unless they are under one of the directories in open_basedir. However, I cannot place any scripts in, say, /homes/u0/apache/cdf/deadlines/. A minimal file foo.php, saved there, containing only: ?php echo htmlbodyHello/body/html; ? Results in the script not executed, with the following error messages: [Fri Jul 6 17:24:53 2001] [error] PHP Warning: open_basedir restriction in effect. File is in wrong directory in Unknown on line 0 [Fri Jul 6 17:24:53 2001] [error] PHP Warning: Failed opening '/homes/u0/apache/htdocs/cdf/deadlines/foo.php' for inclusion (include_path='') in Unknown on line 0 open_basedir's documentation says that it should only restrict directories from where a file can be opened by a PHP script. http://www.php.net/manual/en/configuration.php Many thanks, -- Arcady Genkin --- Full Bug description available at: http://bugs.php.net/?id=11940 -- 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 #11940: ill side effect of open_basedir
From: [EMAIL PROTECTED] Operating system: Solaris 8/sparc PHP version: 4.0.6 PHP Bug Type: PHP options/info functions Bug description: ill side effect of open_basedir safe_mode = On doc_root = /homes/u0/apache open_basedir = /var/www/htdocs/workathome:/var/www/secure:/var/www/tmp (/var/www is a symlink for /homes/u0/apache) In such a setting I should be able to execute PHP scripts from any directory under /homes/u0/apache, but not access any files unless they are under one of the directories in open_basedir. However, I cannot place any scripts in, say, /homes/u0/apache/cdf/deadlines/. A minimal file foo.php, saved there, containing only: ?php echo htmlbodyHello/body/html; ? Results in the script not executed, with the following error messages: [Fri Jul 6 17:24:53 2001] [error] PHP Warning: open_basedir restriction in effect. File is in wrong directory in Unknown on line 0 [Fri Jul 6 17:24:53 2001] [error] PHP Warning: Failed opening '/homes/u0/apache/htdocs/cdf/deadlines/foo.php' for inclusion (include_path='') in Unknown on line 0 open_basedir's documentation says that it should only restrict directories from where a file can be opened by a PHP script. http://www.php.net/manual/en/configuration.php Many thanks, -- Arcady Genkin -- Edit Bug report at: http://bugs.php.net/?id=11940edit=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-DEV] Bug #11894: want posix_getgrent() function
From: [EMAIL PROTECTED] Operating system: Solaris 8/sparc PHP version: 4.0.6 PHP Bug Type: Feature/Change Request Bug description: want posix_getgrent() function I need to iterate over entries in /etc/group with PHP running in safe mode. A posix_getgrent() function would make my life a lot easier (I have to make a local copy of the group file with a cron job right now). Many thanks, -- Arcady Genkin -- Edit Bug report at: http://bugs.php.net/?id=11894edit=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-DEV] Bug #11899: bugs.php inteface improvement suggestion
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: bugs.php inteface improvement suggestion Just a web-interface related suggestion. Searching bug database with the bugs.php page is unintuitive. For example, I entered a search string, and pressed Edit button just because it's a lot closer to the Search for text box than Display button. You can call me dense, but I think that for the dense people like me it would be nice if the buttons and boxes were regrouped a little bit. Put the bug status, type, last comment and search for text boxes together, with Display button *underneath*. Edit button and the bug number text box should be completely separate. Perhaps it's even a good idea to have different backgrounds for the two groups of elements. The page in question is http://www.php.net/bugs.php Thanks, -- Arcady Genkin -- Edit Bug report at: http://bugs.php.net/?id=11899edit=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-DEV] Bug #11523 Updated: File uploads via HTTP POST don't work with Opera browsers
ID: 11523 User Update by: [EMAIL PROTECTED] Status: Closed Bug Type: HTTP related Operating system: Solaris 8, Sparc PHP Version: 4.0.5 Description: File uploads via HTTP POST don't work with Opera browsers Here's what I received from the Opera folks. They admit the bug, but claim that PHP also doesn't implement the RFC 100%. --8 From: [EMAIL PROTECTED] Subject: Your Opera Bug report To: [EMAIL PROTECTED] Thank you for reporting this bug, and for taking the trouble to develop a test page. The bug was known and is fixed in the next release of Opera (5.12) Versions 5.02 and earlier of Opera also function correctly. What happened was that it was noticed that Opera did not comply with the RFC governing multipart mime attachments for forms (where headers should be able to be split across lines). Opera was brought into compliance for version 5.1, but it was then discovered that several major procesing languages (php, coldfusion and miva) do not comply with the RFC either. Previous Comments: --- [2001-06-18 08:38:36] [EMAIL PROTECTED] After I tested this also with non-php CGI script, I'm totally sure that this is NOT php bug but a bad bug in Opera for Linux. I tried also with the Opera/Win32 5.11 and it works just fine. I submitted a bug report to Opera but feel free to do so too. --Jani --- [2001-06-17 15:15:21] [EMAIL PROTECTED] I am developing a web-based system for university students to submit assignments over the web. This involves uploading files via HTTP POST method, with a PHP script on the receiving end. The page I designed works with Netscape Navigator, Mozilla, and Internet Explorer, but not with Opera 5 for Linux or Windows: PHP obviously gets confused by the data that Opera sends. I've set up a test page to demonstrate the behaviour at http://www.thpoon.com/~antipode/test/upload.php with the source code at http://www.thpoon.com/~antipode/test/upload.phps Thanks, -- Arcady Genkin --- Full Bug description available at: http://bugs.php.net/?id=11523 -- 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]
