[PHP] Weird fileupload problem
Hi! I'm working on a simple file upload form here, where the user can upload large zip files containing images to be added to the selected image gallery... However, uploading large files seems to be a little problem.. Whenever I upload large files (the file I'm experimenting with is about 8MB) both the $_POST and the $_FILES-arrays become completely empty. In my post form I have POST_MAX set to 107374182400, and in a .htaccess-file placed in the same directory as the upload scripts I have the following lines; php_flag upload_max_filesize 107374182400 php_flag max_file_size 107374182400 php_flag post_max_size 107374182400 ...so, uploading small files works perfectly, but large files just empties the superglobal arrays... Is there any other settings I have to change for this to work? -- Trond Arve Nordheim - This message is ROT13-encrypted twice for extra security. msg78312/pgp0.pgp Description: PGP signature
Re: [PHP] Weird fileupload problem
On Mon, Sep 09, 2002 at 10:29:04AM -0400, Paul Nicholson wrote: Hey, First of all, you can *not* set the upload size via .htaccess. You have to set it in httpd.conf or php.ini. And you need to use php_value instead of php_flag. Directory /dir/ php_value upload_max_filesize 8M /Directory Actually, that didn't help :) $_POST and $_FILES is still empty, and the httpd.conf (in the virtualhost) reads like this; php_value upload_max_filesize 100M php_value max_file_size 100M php_value post_max_size 100M (tried to apply this both globally in the virtualhost and on a specified directory) ..and there's no .htaccess involved anymore. btw, this was discussed on the list within this monthread the archives the manual! :) I've read the manual, and all about the php variables I have to change... just can't recall reading anything about superglobals beeing emptied out :) Reading the list archives as we speak ;) -- Trond Arve Nordheim - This message is ROT13-encrypted twice for extra security. msg78323/pgp0.pgp Description: PGP signature
[PHP] Unexpected addslashes/stripslashes-behaviour?
I'm just having a little problem using addslashes/stripslashes here, and I'm wondering if this actually is the expected behaviour: I get text from a form post, let's say This sucks :\. I do $text = addslashes($_POST[fieldname]); and stick $text in a DB. When I pull the text back out, and run stripslashes on the text, the result is: This sucks :.. the \ is gone... Is it supposed to do this? As far as I've seen I need stripslashes on data from a DB already addslashed... so.. what's going on? -- Trond Arve Nordheim - This message has been ROT13-encrypted twice for extra security - This mail sent through IMP: http://horde.org/imp/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Unexpected addslashes/stripslashes-behaviour?
Quoting 1LT John W. Holmes [EMAIL PROTECTED]: What are your settings for magic_quotes? magic_quotes_gpc magic_quotes_runtime They're off. Actually I just noticed that I didn't have to stripslashes() the data that came out of the database myself.. don't know why, but I've always been sure I had to use it.. ohwell, thanks :) -- Trond Arve Nordheim - This message has been ROT13-encrypted twice for extra security -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] need help on ereg statement
On Sat, May 04, 2002 at 02:42:34PM +0200, Andy wrote:
if (ereg(^[A-Za-z0-9],$new_passw))
if (!preg_match(/^[a-zA-Z0-9]*$/, $new_passw)) {
echo invalid;
}
preg-power! :)
--
Trond Arve Nordheim
- This message is ROT13-encrypted twice for extra security.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] SQL session handler problem
Hi! I just wrote a SQL session handler class using some info from the example at http://gateway.digitaria.com/~chris/php/mysql_session_handler/. And.. everything works perfectly, until I attempt to set a session variable, and the custom write function get's executed. It seems that the data parameter passed to the function is empty, no matter what I do. The session-id parameter is correct (and users keep their sessions, it seems like things are working except this), but the data parameter is empty. I read in the example on the URL above that if you didn't set session.save_handler to user, something would go bad during write. The session class can be found at http://www.nordheim.no/temp/session.class.phps (no use to paste the whole thing here I guess). Never mind those funny database-class-things in there, it's just a PEAR DB-wrapper (imagine that, a wrapper-wrapper ;). I'm initiating the class like this; $session = new Session(); /* Constructor will set session.save_handler */ $session-setHandler(); /* This will define session handlers */ $session-Start(); /* Executes session_start(). Is that enough? Works with the default session handler ;) */ ..then, I set a session variable: $_SESSION[test] = TESTING; then, the $session-_write() functions gets executed, but the data parameter is blank. Can anyone tell me what I'm doing wrong here? I'm running PHP 4.2.0 on Apache 1.3.24 (Linux). -- Trond Arve Nordheim - This message is ROT13-encrypted twice for extra security. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: SQL session handler problem
On Sat, May 04, 2002 at 01:10:14AM +0200, Trond Arve Nordheim wrote: $session-setHandler(); /* This will define session handlers */ That's $session-setHandler($session) of course.. getting tired here ;) -- Trond Arve Nordheim - This message is ROT13-encrypted twice for extra security. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] HTTP gzip-compression and fopen
Hi.
I was writing a slashdot RSS-parser for my homepage, and wrote a simple
function to fetch the slashdot.rdf-file from slashdot, and parse it
using PEAR's XML/RSS.php.
Here's the core reading the remote file:
$fp = fopen(http://slashdot.org/slashdot.rdf;, r);
if (!$fp) { return 0; }
$raw = fread($fp, 1);
fclose($fp);
Now, it seems like slashdot is doing som on-the-fly gzip-compression (it
sends a Content-Encoding: gzip-header), and that fopen can't cope with
this, and I'm stuck with some binary data. I've tried using
gzuncompress() on the returned data, but that resulted in an error (not
valid gzip-data).
First of all; shouldn't perhaps fopen support decompression of
gzip-compressed http data? That is, is there any reason why it's not
supported ? ;)
Second; how do I decompress that data? I've been reading the manual and
doing some google-searches, but I can't seem to find an answer anywhere.
--
Trond Arve Nordheim
- This message is ROT13-encrypted twice for extra security.
msg58634/pgp0.pgp
Description: PGP signature
Re: [PHP] HTTP gzip-compression and fopen
On Thu, Apr 18, 2002 at 01:55:47AM +0200, Trond Arve Nordheim wrote: Now, it seems like slashdot is doing som on-the-fly gzip-compression (it sends a Content-Encoding: gzip-header), and that fopen can't cope with this, and I'm stuck with some binary data. I've tried using gzuncompress() on the returned data, but that resulted in an error (not valid gzip-data). Hm, sorry, seemed like this was a slashdot-problem, actually. Works now, and I haven't changed anything ;) -- Trond Arve Nordheim - This message is ROT13-encrypted twice for extra security. msg58652/pgp0.pgp Description: PGP signature
[PHP] Mcrypt-problems
Hi! I'm trying to encrypt some password using TripleDES-encryption here... I've followed the documentation for the mcrypt-libraries, but I get a warning (all though it -does- encrypt the text) every time I try to encrypt something; Warning: attempt to use an empty IV, which is NOT recommend My encrypt line looks like this: $crypted_password = mcrypt_ecb(MCRYPT_TripleDES, secret key, $password, MCRYPT_ENCRYPT); If I echo bin2hex($crypted_password) i get output, so it seems to work... I'd just like to know why this warning appears... I'm using Apache 1.3.23, php 4.1.1. Here's the mcrypt version information: Mcrypt v.2.5.10 (i686-pc-linux-gnu) Linked against libmcrypt v.2.4 (the mcrypt-packages are the current available libmcrypt/mcrypt-packages in debian testing) -- Trond Arve Nordheim - This message is ROT13-encrypted twice for extra security. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
