PHP Upload - 500 Internal Server Error

Asked 22/10, 2012 at 8:56 Answered 3/1, 2017 at 23:38

Solved php iis upload fastcgi internal-server-error

The Issue

When uploading files of around 8MB or over, I recieve a 500 Internal Server Error.

All PHP settings in php.ini are correct
maxAllowedContentLength has been set in the web.config

Server Info

As one can probably tell from the maxAllowedContentLength, I am running IIS 7.5, with FastCGI and PHP 5.3.17

Additional Info

I have tried so many different things to get this working but simply cannot find the issue.

However, I have found the following bits of info that may help figure out the root of this problem:

When uploading files (larger ones) using the Media Wiki that I have on the server, I receive the same error, this goes to show that it is not an error in my code.
Most importantly - I managed to upload an 18MB file in the Plesk File Manager, this obviously means that Plesk was able to get around this config issue. I have tried to copy all of the Plesk Control Panel settings over to this domain in IIS but this does not seem to work.
The error is being returned before the script is executed, as I have tried writing exit; at the top to try to get a blank screen, but this is ignored and the 500 error is returned.

I think that the issue lies within the configure command part of the PHP configuration, because when I change the handler mapping of the .php files to use the Plesk php-cgi.exe instead of the usual one, I do not get the 500 Internal Error. Having said that, I cannot leave it on this PHP version as it is Plesk's own exe and there are other configuration issues.

The reason why I think it may be to do with the configure command, is simply because this differs hugely from one phpinfo() to the other.

If you have any ideas or suggestions, please post them. I have tried everything to my knowledge and cannot seem to fix this. If only it was Linux...

Thanks in advance

UPDATE 1

Forgot to add, there are no errors being returned in the PHP error log. As for IIS errors, I do not know where to look

UPDATE 2

This is what I have placed in my web.config file:

<security>
    <requestFiltering>
        <requestLimits maxAllowedContentLength="2147483647" /> 
    </requestFiltering>
</security>

UPDATE 3

With your help, we have managed to get the error displayed by IIS. This is what I am receiving:

PHP Warning: POST Content-Length of 12221448 bytes exceeds the limit of 8388608 bytes in Unknown on line 0

Is that to do with post_max_size?

UPDATE 4

PHP settings as follows (from phpinfo()):

post_max_size = 64M
memory_limit = 128M
max_file_uploads = 20
max_execution_time = 6000
upload_max_filesize = 64M

UPDATE 5

Lastly, just in case anybody can spot any potential issues, Plesk is able to upload large files absolutely fine, so I assumed that their php-cgi.exe was compiled differently. When I read a phpinfo() of their configuration the configure command information was very different:

My configuration:

cscript /nologo configure.js "--enable-snapshot-build" "--disable-isapi" "--enable-debug-pack" "--without-mssql" "--without-pdo-mssql" "--without-pi3web" "--with-pdo-oci=C:\php-sdk\oracle\instantclient10\sdk,shared" "--with-oci8=C:\php-sdk\oracle\instantclient10\sdk,shared" "--with-oci8-11g=C:\php-sdk\oracle\instantclient11\sdk,shared" "--enable-object-out-dir=../obj/" "--enable-com-dotnet=shared" "--with-mcrypt=static" "--disable-static-analyze"

Plesk's Configuration:

cscript /nologo configure.js "--enable-debug-pack" "--enable-cli" "--enable-cgi" "--enable-isapi" "--enable-one-shot" "--enable-pdo" "--enable-intl" "--with-openssl=shared" "--with-pdo-odbc" "--with-iconv" "--with-xml" "--with-xsl" "--with-mysql" "--with-mysqlnd" "--with-mysqli" "--with-pdo-sqlite" "--with-pdo-mysql" "--with-curl=shared" "--enable-mbstring" "--enable-mbregex" "--with-imap=shared" "--enable-sockets" "--enable-shmop" "--enable-soap"

UPDATE (ANSWER) This is extremely weird as the phpinfo() info is saying one thing, but it is obviously being ignored, not sure why.

If I change the post_max_size in Plesk, for that particular domain/sub-domain, then nothing is changed (although it appears to have changed in the phpinfo()). However, if I actually change the post_max_value in the php.ini then this fixes the issue.

The reason why this is not a good way to fix this, is simply because when Plesk updates, the php.ini is overwritten as PHP is updated and resultantly the changes made to the php.ini are lost. Which means that everytime that Plesk updates I will need to make changes tot he php.ini. This is why Plesk offers the ability to change PHP settings without making changes to the php.ini.

Can anybody think of why PHP is ignoring the local value and reverting to the value in the php.ini, even though the php.ini states that the local value is different?

Accad answered 22/10, 2012 at 8:56 Comment(25)

upload_max_filesize and post_max_size in php.ini are correct, really? (I know you've written but just for be sure :)) – Aphorism 22/10, 2012 at 9:5

Yup, they are correct. Have checked it with the phpinfo(). Just to test, I reduced the limits to 2MB and tried to upload a 3MB file, the error I received was my custom error saying 'file too large', not an 'Internal Server Error' – Accad 22/10, 2012 at 9:12

maxRequestLength in web.config? (<httpRuntime maxRequestLength="XXXXXX" />) – Aphorism 22/10, 2012 at 9:16

I tried the 'httpruntime' thing and it returned an internal server error when I loaded the page. Apparently that is for IIS6 not IIS7. The IIS7 one is the one I have used, see update 2 – Accad 22/10, 2012 at 9:19

What do the error logs say about the exact problem? – Dzoba 22/10, 2012 at 9:22

@Dzoba Which error logs should I look at, and where can I find them? Nothing is displayed in the PHP error logs – Accad 22/10, 2012 at 9:23

I don't know, but this looks good: forums.iis.net/t/1189242.aspx and other hits when Googling iis7 error log – Dzoba 22/10, 2012 at 9:25

See this thread for details on php errors: #4764730 - are you sure your error log setup works, does it show other entries? – Dunagan 22/10, 2012 at 9:25

also. is the internal server error coming from IIS or from PHP? If from IIS, disable the IIS custom errors module so you might see the actual problem. See more details here: #1697367 and: serverfault.com/questions/19561/… – Dunagan 22/10, 2012 at 9:31

@Dzoba Have looked all over the Event Viewer and cannot find anything, the links that both of you have posted dont seem to be right in this case – Accad 22/10, 2012 at 9:33

@Dunagan got the error!!! :-) will post up in answer, should be able to work this out now – Accad 22/10, 2012 at 9:34

@Dunagan I dont think it is hitting the memory limit. Meant to say in my last comment that I will post up in question not answer. What do you think of the error I am getting? – Accad 22/10, 2012 at 9:45

Try in the top of your php code those 2 lines: ini_set('upload_max_filesize', '64M'); ini_set('post_max_size', '64M'); (64mb is just an example...) – Hydrastinine 22/10, 2012 at 9:46

@BenCarey could you add to the question all your php settings that you think are relevant (the ones you've checked)? it might be post_max_size, so check that first. – Dunagan 22/10, 2012 at 9:46

@HamZaDzCyberDeV the settings need to be set before the script runs, so on php config, not from the script – Dunagan 22/10, 2012 at 9:47

@Dunagan Will post up all my settings in my question, give me a min :-) – Accad 22/10, 2012 at 9:50

@Dunagan for testing purposes (and re-usability on other hosting providers as well as security reasons), i always did it within the script, and it works fine. Never had any issues with it ... – Hydrastinine 22/10, 2012 at 9:51

@BenCarey one suggestion still. Are you running phpinfo() at the very same directory your script is, or could it be that you have different configurations of post_max_size in different directories? at least with Apache, it's easy to have different configurations in different directories with .htaccess. – Dunagan 22/10, 2012 at 10:31

@Dunagan yes I am, the phpinfo() is being executed at the top of my upload page temporarily – Accad 22/10, 2012 at 10:32

Ok. Cannot think of anything else than a PHP bug, then. – Dunagan 22/10, 2012 at 10:33

@Dunagan I would have agreed with you about it being a PHP bug, however, the Plesk Control Panel has managed to get around it so it must be a configuration issue. I think it has something to do with the way that PHP was compiled because the configure command is very different on the phpinfo() from Plesk, to the one on my domain – Accad 22/10, 2012 at 10:38

@BenCarey Well, I don't think something that is different for a different compilation is a configuration issue, as it cannot be changed later on with configuration values. A compilation configuration issue, perhaps. Anyway, I don't see a way you could change the behaviour that you see without a recompilation of your PHP, and irrelevant of compilation directives, it should be a changeable thing -> it's a bug. – Dunagan 22/10, 2012 at 10:46

Also, Plesk control panel could be housing a workaround upload component of their own, something similar what I linked in my answer. – Dunagan 22/10, 2012 at 10:48

@Dunagan how would I go about re-compiling PHP? Would I have to re-install it? Should I post up the different configure data to see if there is anything there that may be causing this? – Accad 22/10, 2012 at 10:48

@BenCarey I don't think that's something you want to do, and it's probably not even possible for a hosted solution - at least not unless different upload components are out of the question, too. Yes, it would require re-installation. And yes, you could post the configure data, in case there would be something there. – Dunagan 22/10, 2012 at 10:50

If you look at the source code of PHP, you can see on the file php-5.4.8-src\main\rfc1867.c line 706-709 this:

if (SG(post_max_size) > 0 && SG(request_info).content_length > SG(post_max_size)) {
    sapi_module.sapi_error(E_WARNING, "POST Content-Length of %ld bytes exceeds the limit of %ld bytes", SG(request_info).content_length, SG(post_max_size));
    return;
}

Same is there also in file php-5.4.8-src\main\SAPI.c. So, the message PHP Warning: POST Content-Length of 12221448 bytes exceeds the limit of 8388608 bytes in Unknown on line 0 is about post_max_size setting. You have confirmed from using phpinfo() that you have this setting configured correctly, but it seems to be using the default value of 8M anyway.

As to why, see this thread:

As it turns out, on Windows, you can only set ini directives that are marked PHP_INI_USER per directory. Unfortunately, upload_max_filesize and post_max_size are both PHP_INI_PERDIR. From the PHP docs at http://php.net/manual/en/configuration.changes.php

The settings for the directory would be active for any script running from this directory or any subdirectory of it. The values under the key should have the name of the PHP configuration directive and the string value. PHP constants in the values are not parsed. However, only configuration values changeable in PHP_INI_USER can be set this way, PHP_INI_PERDIR values can not.

So even though Plesk has an interface to change those directives, and even though phpinfo() picks up on them, they do nothing to change the actual max upload sizes. Plesk should not allow you to change those on Windows, and phpinfo() should not report the change, but what can you do.

So, it's post_max_size, and it needs to be set on php.ini. Plesk setting simply will not work, even though phpinfo says otherwise. I also opened a bug entry on phpinfo behaviour as there didn't seem to be an entry for it.

Dunagan answered 22/10, 2012 at 9:59 Comment(3)

I have found the answer, but it is not good, will update my question in a min so you can see :-) – Accad 22/10, 2012 at 11:7

Answer aceepted, thank you very much for you help. Isnt it pathetic that Plesk would allow you to change values that cannot be changed. I have quite literally spent over 12 hours on this issue now, and it was what I suspected it was in the first place!! If only I had bothered trying the php.ini instead of using the Plesk Panel... Speechless... Thank very much for your time +1 – Accad 22/10, 2012 at 11:29

Opened a bug report also for this, see if they would at least fix phpinfo output: bugs.php.net/bug.php?id=63330 – Dunagan 22/10, 2012 at 11:48

This is a fairly common error and is due to the fact that the size of data being uploaded does not match file size: even if you POST max size is not exceeded by the file size, it could be by the uploaded data size.

See this page in the PHP manual.

; Maximum size of POST data that PHP will accept.
post_max_size = 8M

Another source of troubles (for VERY large texts) is UTF8 encoding. You might find yourself with a "six megabytes" TEXTAREA that is actually 6 mega*characters*, and with international codepoints it might run to, say, 8.2 megabytes. Thus you get an apparently contradictory situation of "six megabytes data exceed the configured 8 megabytes limit".

Update

You report two apparently contradictory facts:

PHP settings as follows (from phpinfo()):

    post_max_size = 64M

and

PHP Warning: POST Content-Length of 12221448 bytes exceeds the limit of 8388608 bytes

It is clear from the PHPINFO that the limit for POST is 64M. Yet the error says that the limit is 8M (the default). So it seems to me that your code is talking to two different PHP implementations (Two different virtual hosts? A CGI version and a non-CGI version in the same host? Two different machines?)

Apologue answered 22/10, 2012 at 9:44 Comment(6)

Have played with this, but doesnt seem to be the issue :-( – Accad 22/10, 2012 at 9:58

I noticed something strange in your report. Yes, this is not the usual limit that bites me every now and then (I seem to be incapable of remembering this PHP quirk), you're up against something weirder. – Apologue 22/10, 2012 at 10:22

In reply to your update re. the two different machines. Plesk manages all the virtual hosts etc, so I do not know whether this is causing the problem? – Accad 22/10, 2012 at 10:27

@BenCarey But if you have checked the values in phpinfo() in the very same script that has the issues, I don't see how that could be the cause either. – Dunagan 22/10, 2012 at 10:40

Excatly, you are now where I am at! No idea what could possibly be causing this, and how Plesk managed to get around it! – Accad 22/10, 2012 at 10:44

I have found the answer, but it is not good, will update my question in a min so you can see :-) – Accad 22/10, 2012 at 11:6

IIS will re-use the FastCGI processes. You will need to kill off any old processes to get php.ini to reload.

Edit the FastCGI module and edit 'monitor changes to file' and select the php.ini file. This will force the child processes to restart whenever you save an edit.

Lazaro answered 22/10, 2012 at 11:22 Comment(2)

I am aware of this, a simple restart of IIS is all it needs – Accad 22/10, 2012 at 11:25

OK great. I know a few people that completely missed this, wasting hours on something simple. – Lazaro 22/10, 2012 at 11:35

You could turn the limits to -1, that way, you won't ever have troubles about the size of the files. It is probably no the best solution as you are basically saying "if I don't see it, it doesn't exist", but believe, it's really reliable and will always work.

Consalve answered 3/1, 2017 at 23:38 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

The Issue

Server Info

Additional Info

Update

Recommended topics

Hot tags