I'm using jquery-file-upload plugin to upload some files.
I have a bind to the add callback where I collect the files to upload and on form submit i'm issuing the 'send' command to begin the upload.
The problem i'm facing is that the fail callback is called upon successful upload with the following error message:
"Uploaded bytes exceed file size"
can anyone explain me what does this error mean? and why I keep getting it?
I appreciate the help.
10x
I was getting this error as well but I was setting the dataType value to be JSON.
I remove the dataType open and stopped getting this error.
This only worked for me as I was not getting Json back
I was also getting this kind of error. And it took me a whole day to find the cause of the problem. So, I changed a lot of things and among them:
I explicitly set "upload_tmp_dir" directive in php.ini - it was
irrelevant;
Checked and increased values for both "upload_max_filesize" and "post_max_size" directives in php.ini - it was also not the cause.
Created all the folders in my document root directory: "images/" and "images/temp/" - didn't help though is necessary.
The problem was that there was a separate root for AJAX post request for image preliminary upload (Silex/Symfony library), and in the example I copied, the author (deliberately) left out the "url" option from the request, as in:
$('#fileupload').fileupload({
dataType: 'json',
url: '/post/upload', // this was missing
replaceFileInput: false,
fileInput: $('input:file'), ...
At the same time, the form, where this element belonged to, had its own route set to "/post/" and, with "url" option missing, the plug-in, obviously took it from the parent form.
As such, no controller was called, the uploaded file was unprocessed, and the text of the error was misleading.
PS. This "auto substitution" by the plug-in might also affect the methods used for request (PUT or POST), as I used both in controllers - "PUT" for the form and "POST" for the fileupload management, but I didn't check.
I tried reviewing all available messages in console and I found this
always: function(e, data) {
console.log(data.jqXHR.responseJSON.files[0].error);
In my part, I got the error due to the file I'm uploading exceeds the upload_max_filesize directive in php.ini
The won't give the you the exact error.
console.log(data.messages);
Make sure your form only has inputs that are what AWS expects. Do not add extra form fields of your own. Or if you do, remove them with JS before the AWS upload begins.
Related
So I'm making a browser based game, and in order to create an account for this game I have the JS file call a PHP file (POST) to write an XML file.
This works, I get the file in cPanel, in the right directory, with the right content. Meaning I can open it, but only in cPanel. When I try to access it via browser I get a 404, but only for about 30 min, then it'll just magically start working.
This same PHP file is called later on in the game to update XML files, and the same thing happens. I can confirm that the PHP works exactly as it should, because I can see that the file/directory is perfect.
Here's the interesting bit, if I create an XML file manually or update it manually, it works instantly. It's only the XMLs created by the PHP file that take forever to load.
It's like the server doesn't realize that there was a change on it, until half an hour after the fact. That is, unless I did it manually.
My PHP:
<?php
$filename=$_POST['fileTo'];
$newfile=fopen($filename,"w")or die('Can not open');
$string=$_POST['stuff'];
fwrite($newfile,$string) or die('Could not write');
fclose($newfile);
?>
My AJAX call:
$.ajax({
type: 'GET',
url: writeDirect,
dataType: 'xml',
success: function(result) {
},
cache:false,
error: function(error) {
$.post('PHP/Accounts/creatAcc.php', { fileTo: userWrite, stuff: writeStuff }, function() {
signIn(userATFS, passCe);
});
}
});
Update:
I've decided to access the games directory directly from the browser. This gets even more interesting.
First thing I did was create a new account called testFile, I get the standard error on the GET because the game can't access the newly created account.
Then I opened the directory in Chrome, this is interesting:
The index clearly shows that testFile.xml exists
Then I try clicking on it, but this is where it breaks
The images 404 despite the file clearly existing
And no, changing the permissions on testFile.xml did not change anything.
I believe I've found the answer. I think it was just that server that was weird like that. I was using x10 basic and decided to switch over to another service and now it works.
I'm using Dropzone.js for my website. I'm in the need of uploading bigger files than the default maxFilesize of 500MB.
I tried to change the number in the .js file. Now the file seems to be accepted but there is no (visible?) progress in the upload. The file has no red cross and is stuck at zero percent of the upload.
Any ideas what I might be doing wrong? Or is this some kind of bug?
I just tested it in Chrome and it worked fine. (Which browser are you using?)
It might be that your upload is just taking so long that you don't see an update immediately.
First things first: you shouldn't change properties in the .js file itself. This way you wont be able to upgrade to a newer version of Dropzone without headaches. So configure your dropzone the way it's recommended on the website.
About the upload,... it's really hard to tell what might be wrong without a look at it. What I suggest, is that you add some kind of debugging information on the status updates, to see if it's really just your upload being very slow.
Try this code and see if it doesn't solve your problem:
<form id="my-dropzone" action="/target" class="dropzone"></form>
<script>
Dropzone.options.myDropzone = {
maxFilesize: 500,
init: function() {
this.on("uploadprogress", function(file, progress) {
console.log("File progress", progress);
});
}
}
</script>
If you can see the console output in regular intervals then the upload is working fine but just takes a while to finish.
The Dropzone.options must be out of document.ready or it wont work.
Just for the record, because this post is from along time ago.
I solved it changing in the php.ini file parameter 'post_max_size' from my server. Maximum size of POST data that PHP will accept.
And then reboot the Apache Server.
Add to httpd.conf file:
<Directory "/tmp/">
LimitRequestBody 256000
</Directory>
After, restart apache!
Reference: https://www.cyberciti.biz/faq/apache-limiting-upload-size/
I have a bit of JavaScript using jQuery that loads data with a quick $.get(url, function(response){ /* ... */}); The data is a straight up text file that is then handled by the JavaScript in that response function.
This has worked for me quite nicely, but I just ran into this problem on my machine: Using the same code, I now get an error saying:
XML Parsing Error: not well-formed Location:
moz-nullprincipal:{74091275-3d54-4959-9613-5005459421ce} Line Number
1, Column 16: image:tiles.png;
---------------^
If I load this from another server, it works perfectly. It's only when I host it on my own PC that I get this error (note that it previously worked perfectly on my own PC as well, which is running Ubuntu and serving the page with Apache). After much headbanging, I found that if I change the extension on the filename I'm loading, it works fine. The file was previously named "test.sprite", and that is when I got the error. If I renamed it to "test.txt" it loads fine.
This error ~seems~ to coincide with a recent upgrade on my system. I upgraded Ubuntu 10.something to 12.04. I'm assuming there was some sort of update in the Apache config that I didn't notice which is causing it to send different headers depending on the extension of the file (the two named here are identical - the .txt is actually just a symlink to the .sprite).
So I have a solution to my immediate problem, but I'd rather not bow to the system's idiosyncrasies. Any idea how I can fix this without renaming the file?
Please note that I'm not an apache expert, but I'll have a crack with pointing you in the right direction.
If undefined, the jQuery AJAX functions will assume the content-type is whatever header Apache has sent back. You can quite simply see what the response is by running your code in Chrome, opening developer tools (Ctrl + Shift + J) and choosing "Network". After clicking on the relevant request you will see the headers coming back, including the content-type.
In your Apache configuration the content-type for the sprite is probably not defined. You can add this with the following line:
AddType 'text/plain; charset=UTF-8' .sprite
This should be in a configuration file parsed by Apache - depending on your version this could be apache.conf, httpd.conf, or another file.
I hope this helps or at least points you in the right direction. Remember to configtest before restarting Apache!
Check out the content-type of the response header, make sure the header you received from the server and your local machine have the same content-type, i.e. same file type , same encoding, something like this: "content-type:text/html; charset=UTF-8".
I'm attempting to upload a file and the server-side language used is Perl. The CGI module version is 3.15
for some weird reason I can upload any file below 32KB, but beyond that that filesize, I received the following error:
CGI.pm: Server closed socket during multipart read (client aborted?).
I tried setting the following parameters for CGI
use CGI ':standard';
$CGI::POST_MAX=-1;
$CGI::DISABLE_UPLOADS=0; # Allow file upload
but I still receive the error.
I hear that this problem is fixed in the newer version of CGI, but I cannot upgrade the CGI module, is there an alternative?
Any ideas are welcome !!!
I see you are setting $CGI::POST_MAX = 1, which is 1 byte.
Trying increasing it: 1024 * 100.
From the docs:
$CGI::POST_MAX
If set to a non-negative integer, this variable puts a ceiling on the size of POSTings, in bytes. If CGI.pm detects a POST that is greater than the ceiling, it will immediately exit with an error message. This value will affect both ordinary POSTs and multipart POSTs, meaning that it limits the maximum size of file uploads as well. You should set this to a reasonably high value, such as 1 megabyte.
The key to your problem seems to be here:
CGI.pm: Server closed socket during multipart read (client aborted?).
The error message seems to indicate that your server is closing the connection. If you are using Apache, nginx, whatever, check their config settings to increase maximum post request body size.
Read the whole documentation for CGI.pm, even if it's long. Somewhere there is a sub which sets a security maximum for file uploads. This is intended to make your server more DDOS-resistant. Just set a value you prefer. This would solve the 32kB part of the problem...
(I'm sorry that this wild guess didn't solve anything. Consider this answer deleted.)
I am trying to use django-filebrowser. I have installed in correctly according to the instructions, but i get a JS error every time i try to upload a file.
I should note that i am able to browse to 'filebrowser/browse/', create directories etc.
The problem is that when i chose to upload a file, i can see in the html source that a file 'CollapsedFieldsets.js' is included but cannot be found.
The location of this file is supposed to be here: django-install/django/contrib/admin/media/js/admin/ but the file is nowhere to be found.
django-filebrowser references this JS file in filebrowser/templates/upload.html
The error i get is:
invalid object initializer
$('#id_file').uploadify({
That probably happens because the file in question cannot be found.
I am using Django 1.3 and that file is not included in the download.
Please help!
I may have got the same trouble some days ago when I was using django-filebrowser. I can also create the directory, but when I click the 'browse' button, it fails with the same error that you got: 'CollapsedFieldsets.js' can not be found.
at last, I found that:
MEDIA_URL = 'http://domain/static/'
FILEBROWSER_URL_FILEBROWSER_MEDIA =MEDIA_URL+ 'filebrowser/'
because the MEDIA_URL has no 'www', so when I visit my website with no 'www', the filebrowser works well; but if with 'www', I will still get the error.
I am not sure this answer is right, hope it can help you.