I am using a slightly modified version of phUploader script that works fine for small files. But when I try to upload files larger than 1MB it fails by giving this undescriptive error:
General upload failure.
Nginx error log does not show any evidence. I have set
upload_max_filesize = 200M
post_max_size = 200M
memory_limit = 128M
in the php.ini
and
client_max_body_size 200M;
in nginx.conf.
The odd thing is that the script used to work well on the same server (before an upgrade on Debian 6 server) and already works well on another Debian 6 server with the same nginx and php configs. So I'm really out of ideas and appreciate your hints.
You're getting an undescriptive error because the script you're using isn't properly displaying the actual error (line 252).
Modify the script to echo or log the value of $_FILES['file']['error'] instead of "General upload failure." Then, you should see a more appropriate error code. The PHP Manual has a section that explains what the error codes mean.
Related
I need to be able to upload files ranging in size in 500MBs in CKan. I have installed CKAN using packager in Ubuntu 16x version. It works nice with me being able to set up organizations and creating new datasets. However, I am not able to upload files more than 100mb in size. I get error
413 Request Entity Too Large error' nginx/1.4.6 (Ubuntu)
Based on various forums and suggestions, I have changed
client_max_body_size to 1g in file /etc/nginx/nginx.conf. I have tried various ways such as setting this parameter to 1000M/1g/1G values one at a time and nothing seems to work. My all uploads beyond 100MB keep failing.
I also learnt that changing production.ini or development.ini(ckan.max_resource_size) file would help and I tried that too but it doesn't work. Please suggest what could be done. nginx is a proxy server and apache is web server that comes with default cKan packager.
In the end of /etc/nginx/nginx.conf, you have this include directive :
include /etc/nginx/sites-enabled/*;
that will include /etc/nginx/sites-enabled/ckan. This file contains the directive :
client_max_body_size 100M;
Change it, don't forget to change the ckan.max_resource_size /etc/ckan/default/production.ini, restart nginx and apache and it will work normally.
I can download 1+ Gb files with no problem from my server. Today uploaded 2.3 GB file and discovered that I can't download it, downloading gets interrupted after 1GB and it happens for every user. I tried Firefox 15, latest Chrome, and IE9.
Server:
Apache 2.2.22
fcgi
eAccelerator
CPnginx
How can I resolve this?
I think I just faced the same problem, hopefully this might help others.
My server is set up to proxy requests to Apache through Nginx using the ngx_http_proxy_module. The proxy_max_temp_file_size directive of this module defaults to 1024m and is what was causing my problem.
Try adding the line proxy_max_temp_file_size 5120m; within a http, server or location directive in your nginx.conf file and reload nginx's config file with /etc/init.d/nginx reload.
Looks like the default max download size apache sets is around 2 Gb and you can override it by tweaking LimitRequestBody in your httpd.conf. Not sure why it would stop at 1 Gb though, that would make me think the problem is something else.. Hope this helps.
I am running an Apache 2.2.3 proxy server to hide my backend machines from users. I added a file upload service to my webservices; however, files larger than 128 kb are returning http Status Code of 413. I know this means Request entity too large, and I have scoured the internet looking for a solution.
I have changed my php.ini file to have max_execution_time = 3000, max_input_time = 6000, memory_limit = 128M, post_max_size = 20M, upload_max_filesize = 20M, default_socket_timeout = 6000. This didn't help, as I suspected it wouldn't. I am doing a Rest call from Java for the webservice it is not PHP.
I have changed the maxHttpHeaderSize in server.xml to 20000000 on the proxy connector to try to allow for more information to flow through. Again this did nothing and my limit is still at 128 kb.
I have also added the LimitRequestBody 20000000 Directive to the Location block for the webservice files will be uploaded from. This again didn't work.
Currently all 3 are in place without any improvement. I am still only able to send max 128 kb files through the proxy.
When I try to send a file directly to the backend machine without using the proxy it works perfectly fine without taking into account the size.
Any suggestions on how to fix this will be very much appreciated.
Thank you.
I have figured out what the problem was, and where the 128k limit occurs.
In mod_ssl it uses the default ssl negotiation size as 128k, when doing an upload we automatically renegotiate for security purposes.
I had to add and modify the SSLRenegBufferSize directive in the Locations and Directories that needed a larger than 128k buffer on renegotiation. This has worked like a charm for me.
Hope it helps anyone else that experiences this limit, or had this question.
I've been trying to figure out how to resolve this error with all the new pages I create:
Server error!
The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there was an error in a CGI script.
If you think this is a server error, please contact the webmaster.
Error 500
localhost
2011/11/28 13:36:56
Apache/2.2.17 (Win32) mod_ssl/2.2.17 OpenSSL/0.9.8o PHP/5.3.4 mod_perl/2.0.4 Perl/v5.10.1
Well, it all started when I increased the security on MySQL by setting some more passwords, I think. I figured I'd get a better error report if I turned error reporting on in php.ini, but it's not in my /apache/bin folder.
Alright, so I have no idea what to do. I've also got this line in xampp: MySQL database DEACTIVATED.
Any idea what might be happening? Also, please let me know if this should go to superuser.
If you're on Linux, try a "find", like this:
find / -name php.ini print
Another approach is to create a "phpinfo.php" in your Apache DocumentRoot folder, and let PHP tell you where you should put your php.ini:
<?php
// Create this file in your Apache root,
// then browse to http://localhost/phpinfo.php
// Look for "Configuration File (php.ini) Path" in the resulting output
phpinfo ();
?>
Use the find feature in Linux, as specified by paulsm4 to find php.ini.
Use ctrl+f in Windows and search for files and folders -> php.ini to find it in Windows. I recommend you do this from your web server's root directory rather than from some other location; otherwise, it may fail.
If you're experiencing a 500 error, you should check your Apache log files. They can be found in the /apache/logs folder in the file error.log, I believe. I emptied the file and then caused the error to isolate it. The information lead me to the answer.
In my case, the reason I was getting a 500 error was because my .htaccess file was referencing a .htpasswrd file that did not exist. I changed the line of code in the .htaccess file that was targeting the .htpasswrd file to target an existing .htpasswrd file that I wanted to use. I could have just as soon copied a properly formatted .htpasswrd file or made one from scratch, though.
I've read at multiple sources that 500 errors have many causes. So, none of these steps are guaranteed to work for you. If they do not, I wish you luck, and I hope that you will post a reply telling me how you fixed your 500 error, too--or, a link to a resolved question about a 500 error.
I'm getting 500 Internal Server errors when I try to make an HTTP POST to a specific address in my app. I've looked into the server logs in the custom log directory specified in the virtual hosts file, but the error doesn't show up there so debugging this has been a pain in the ass.
How do I cause Apache to log Internal 500 errors into the error log?
This is an Ancient answer from 2013, back when PHP was new and security wasn't an issue:
Here in the future it's a security risk to dump errors to screen like this. You better not be doing this in any production setting.
Why are the 500 Internal Server Errors not being logged into your apache error logs?
The errors that cause your 500 Internal Server Error are coming from a PHP module. By default, PHP does NOT log these errors. Reason being you want web requests go as fast as physically possible and it's a security hazard to log errors to screen where attackers can observe them.
These instructions to enable Internal Server Error Logging are for Ubuntu 12.10 with PHP 5.3.10 and Apache/2.2.22.
Make sure PHP logging is turned on:
Locate your php.ini file:
el#apollo:~$ locate php.ini
/etc/php5/apache2/php.ini
Edit that file as root:
sudo vi /etc/php5/apache2/php.ini
Find this line in php.ini:
display_errors = Off
Change the above line to this:
display_errors = On
Lower down in the file you'll see this:
;display_startup_errors
; Default Value: Off
; Development Value: On
; Production Value: Off
;error_reporting
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATED
The semicolons are comments, that means the lines don't take effect. Change those lines so they look like this:
display_startup_errors = On
; Default Value: Off
; Development Value: On
; Production Value: Off
error_reporting = E_ALL
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATED
What this communicates to PHP is that we want to log all these errors. Warning, there will be a large performance hit, so you don't want this enabled on production because logging takes work and work takes time, time costs money.
Restarting PHP and Apache should apply the change.
Do what you did to cause the 500 Internal Server error again, and check the log:
tail -f /var/log/apache2/error.log
You should see the 500 error at the end, something like this:
[Wed Dec 11 01:00:40 2013] [error] [client 192.168.11.11] PHP Fatal error:
Call to undefined function Foobar\\byob\\penguin\\alert() in /yourproject/
your_src/symfony/Controller/MessedUpController.php on line 249
I just ran into this and it was due to a mod_authnz_ldap misconfiguration in my .htaccess file. Absolutely nothing was being logged, but I kept getting a 500 error.
If you run into this particular issue, you can change the log level of mod_authnz_ldap like so:
LogLevel warn authnz_ldap_module:debug
That will use a log level of debug for mod_authnz_ldap but warn for everything else (https://httpd.apache.org/docs/2.4/en/mod/core.html#loglevel).
Check your php error log which might be a separate file from your apache error log.
Find it by going to phpinfo() and check for error_log attribute.
If it is not set. Set it: https://stackoverflow.com/a/12835262/445131
Maybe your post_max_size is too small for what you're trying to post, or one of the other max memory settings is too low.
If your Internal Server Error information doesn't show up in log files, you probably need to restart the Apache service.
I've found that Apache 2.4 (at least on Windows platform) tends to stubbornly refuse to flush log files—instead, logged data remains in memory for quite a while. It's a good idea from the performance point of view but it can be confusing when developing.
Please Note: The original poster was not specifically asking about PHP. All the php centric answers make large assumptions not relevant to the actual question.
The default error log as opposed to the scripts error logs usually has the (more) specific error. often it will be permissions denied or even an interpreter that can't be found.
This means the fault almost always lies with your script. e.g you uploaded a perl script but didnt give it execute permissions? or perhaps it was corrupted in a linux environment if you write the script in windows and then upload it to the server without the line endings being converted you will get this error.
in perl if you forget
print "content-type: text/html\r\n\r\n";
you will get this error
There are many reasons for it. so please first check your error log and then provide some more information.
The default error log is often in /var/log/httpd/error_log or /var/log/apache2/error.log.
The reason you look at the default error logs (as indicated above) is because errors don't always get posted into the custom error log as defined in the virtual host.
Assumes linux and not necessarily perl
The answers by #eric-leschinski is correct.
But there is another case if your Server API is FPM/FastCGI (Default on Centos 8 or you can check use phpinfo() function)
In this case:
Run phpinfo() in a php file;
Looking for Loaded Configuration File param to see where is config file for your PHP.
Edit config file like #eric-leschinski 's answer.
Check Server API param.
If your server only use apache handle API -> restart apache.
If your server use php-fpm you must restart php-fpm service
systemctl restart php-fpm
Check the log file in php-fpm log folder. eg /var/log/php-fpm/www-error.log
Please check if you are disable error reporting somewhere in your code.
There was a place in my code where I have disabled it, so I added the debug code after it:
require_once("inc/req.php"); <-- Error reporting is disabled here
// overwrite it
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
Add HttpProtocolOptions Unsafe to your apache config file and restart the apache server. It shows the error details.
In my case it was the ErrorLog directive in httpd.conf. Just accidently noticed it already after I gave up. Decided to share the discovery )
Now I know where to find the 500-errors.
Check that the version of php you're running matches your codebase. For example, your local environment may be running php 5.4 (and things run fine) and maybe you're testing your code on a new machine that has php 5.3 installed. If you are using 5.4 syntax such as [] for array() then you'll get the situation you described above.
Try accessing a static file. If this is not working either then
go to all directories from the root "/" or "c:\" to the directory of your file and check if they contain ".htaccess" files.
I once left a file in "c:\" and it had the most strange results.