HTTP 0 Error when Uploading ALL Files

Check that your settings are actually correct for max upload and max post size. Often times hosts will cap your settings (say at 20M) no matter what options you specify in your php.ini or .htaccess file. Check phpinfo() to ensure that your settings are actually taking effect.

Hi quicksketch,
That was the first thing I checked. I'm running this project off of a dedicated host, so I made my changes in the server's php.ini and looked at phpinfo to ensure that it worked. (It was at 64M before I bumped it up to troubleshoot, tonight.)

Hm. Further weirdness. It seems that of the four FLV files I need to upload before tomorrow morning, only one of them uploads successfully. It's also bigger than the ones that fail, at 123M. Uploading a large mp3 file (53M) also works. I've been fighting with this literally all day at this point. I'm starting to get the feeling that I'm going to need to put them up using a static page instead of Drupal.

Have you installed the Mime Detect module? There's a problem specifically related to FLV files noted in that queue: #227167: flv support?

Thanks for the suggestion. I've now tried adding the FLV entry into the magic database and even hard coding it in the mimedetect module in its "additional formats" array.

The first change still gave me HTTP 0 errors.

The second gives me a new error:
"The selected file Solution_Marketing.flv could not be uploaded. The file contents (video/x-flv) do not match its extension (flv)."

I also noticed that some people had said there could be problems relating to the bundled copy of fileinfo conflicting with the server copy. I tried the fix outlined in the mimedetect issue queue #270607: 500 server error at admin/logs/status (though it says it's for the 5.x version.) This change didn't do anything either; still getting HTTP 0 errors upon upload.

Could you try just disabling the Mime Detect module and seeing if that allows the upload? Obviously not a permanent solution but I'd just like to know if Mime Detect is solely responsible for the problem or if its something in FileField.

I've just deactivated Mime Detect and attempted to upload the file again. Still getting the same HTTP error 0. Is there any way to get more debug information out of FileField on what exactly is going on when it fails like this?

You can check Firebug's HTTP request history and see what returned HTML you're getting back from Drupal. That sometimes helps determine what is happening on the Drupal side of things during the AJAX request.

When enabling Net monitoring in Firebug, there is only the one GET entry for the original HTML page. Under XHR, I see the transfer progress entries, but there are no other requests listed.

Also, I cloned a backup of the site to a Virtual PC install of Ubuntu Server 8.04 with PHP 5.2.4-2ubuntu5.6. This local copy of the site, running on Ubuntu, allows me to successfully upload the FLV files with FieldField. I guess this means it's a problem between server configuration and FileField?

The production server causing all my problems is Fedora-based, running PHP 5.2.6. I can dig up more server specifics if you have guesses as to what I should be looking for. Aside from the PHP versions, nothing really stands out to me between the two.

Oh right, that was a bad suggestion on my part. Since it's a file upload request, it's done via an iFrame and won't show up in Firebug. Shoot. I don't know of any common problems other than what's posted to the FileField handbook: http://drupal.org/node/423478, which is basically the PHP max upload, post max, and memory limit, plus working around this really strange plugin called Suhosin, which I wouldn't think would be installed on a dedicated server such as yours.

I was encountering the same error when uploading images (jpg, png, gif) using filefield 6.x 3.0 There was some very strange behavior. For instance FF on OSX worked fine, but FF on Vista did not. Etc.. I wound up reverting back to filefield 6.x 3.0rc1 and it seems to work fine across the board.

Check that, it seems to clear it up only in some cases. I'm still at a bit of a loss.

Hi,

This is happening to me not only with large files but all files. It has been happening to all projects that requires filefield. In short, rotor banner, imageapis, ubercart. Anything and everything that uses this module produces the error. And i've made sure it is not theme or server platform related as i have ran it with all theme and windows/linux installations. Please advice. I really need to get this working.

Thank you.

-Xyber.

This is also happening to me for all file uploads. I believe this is only an issue since updating to 3.0

I got same problem with Opera 10 Beta release. In Firefox 3.5 (both WinXPSP3) it works fine.

The problem for me was a conflict with FCKEditor as detailed at http://drupal.org/node/432038. I fixed by moving to the wysiwyg module instead.

I am having this same problem with Image uploads. I don't have any other kind of uploads on my site.

Stepping back to RC1 did not solve my problem.

This seems to be a Firefox issue. I'm running FF3.5rc1. When I try to upload a file using Chrome, it works fine.

rc1? Man, there is rc3 already. Check it. I'm using it, and it works fine.

I tried with latest version of ff still produces this error... Anyone had any luck yet?

New update, it works fine with IE. So i guess it is indeed FF issues. But majority of my users use FF. Any ideas how to fix?

-Xyber.

I am getting the same problem as well with FF v3.5.
After reading thru all the problems I followed this persons advise:

http://drupal.org/node/297035#comment-1609590

That seemed to work for me.

I have the same problem. But it does not work in any browser for me. /[path]/filefield/ahah/[content type]/field_[field_name]/0

Is any help on the way for this? Thanks. Kevin

subscribing

Uploads work fine logged in as user 1 but not for other logged in users.

3 sugestions:

Try using the ImageMagick Image toolkit instead of GD
If using ImageMagic, check it is installed correctly at admin/reports/status
Check your file upload limits at /admin/settings/uploads

Subbing

I was getting this error for all file uploads, but then I switched from 3.1 to 3.0 and now everything works.

hi hypatia, how can i download old versions? do you have a link to the 3.0 build? thanks! Kevin

I didn't download it from anywhere -- I just had the old filefield-6.x-3.0.tar.gz that I downloaded awhile back. I'm attaching it here.

Thanks a million!

i'm still having no luck. still getting the An HTTP error 0 occurred.
/filefield/ahah/news/field_company_logo/0

maybe the next build will magically solve it. any idea when the next release is scheduled to happen?

thanks
Kevin

The 3.1 release just came out and there aren't any plans for a new release. Here's a checklist for you:

- Turn off Theme Developer Tool (disable the module entirely)
- Turn off Devel querying logging
- Check/increase your PHP max_upload_size and max_post_size
- Disable ad-blocking plugins in Firefox
- Turn off FCKeditor (the module) if you're using it. Use the WYSIWYG project for FCKeditor instead.

Edit: Updated list.

hi quickstretch,

i appreciate your help. for the record, i do not use theme developer tool or devel. i tried turning off ad blocker and still get the error. my max upload size is 256MB.

i have no idea what the problem is. what i do know is everything was fine till i updated the module. whatever the update changed it did not change back when i tried to go retrograde with a previous version.

thanks again
Kevin

I have tried a clean install on a new Drupal site as one of only a couple modules and still get the HTTP error. So all I can imagine is it is a server setting issue. What has changed in the latest release that might trigger such and error so i can try to chase it down with my admin. It has been more than a week now without images. Thanks. Kevin

Hi All,

I think this is a mozilla firefox problem. If i were to try it with the latest firefox on all PCs i have access to, it produces this error. If try it with IE, it works fine. Too bad this module is not suitable with FF. I love both FF and Drupal...

-Xyber.

Xyber,

What version of IE are you testing on? It does not work with IE 7 as far as I can tell. It does not work with Opera either. I can't get it to work on anything otherwise i would use that browser just to upload images. As far as not being a FF compatible module in general, that's not exactly true. I've been using the module for about six months now strictly with FF with no problems. My problem began when I updated to the most recent version of the module. Since then, every browser gives me an error. The strange thing is I can't even get it to work by reverting now to an early version. Talk about frustration and helplessness. I'm trying to find another solution now.

try uploading different files of different sizes. I too had this problem and by doing that I found out that I could upload file of upto 12k in some browsers, and more like 15k in others. It was seemingly random. I increased the upload limit at /admin/settings/file-system and all was well. Got knows how, but it was set on 0.

where do you see an upload limit config option at at /admin/settings/file-system? i see only an option for configuring paths and public/private download method. cheers, kevin

Hi,
If i am not mistaken, it is in your php.ini.

-Xyber.

Hi iteego,

I've used all three version of IE(6/7/8). All successful. As for firefox, i updated to the latest 3.5 version and eversince then, i couldn't get it to work, even to backtrack and use 3.0

-Xyber.

Hi iteego,

I've used all three version of IE(6/7/8). All successful. As for firefox, i updated to the latest 3.5 version and eversince then, i couldn't get it to work, even to backtrack and use 3.0

-Xyber.

I'm having a similar issue, even after doing everything in the checklist from #33. Small files are OK, the limit seems to be somewhere around 1.3M. All memory/upload/post limits are set to 48M by the host. The error happens consistently in Firefox on Ubuntu, Firefox and Safari on OS X and on Windows.

Running exactly the same code with the same database content on my local environment (Ubuntu) runs without a problem, so it must have to do with some server configuration. The only difference I can find is that the server has the PHP uploadprogress module version 0.9.2 and my local environment has version 1.0, but the documented changes between the two versions only include a fix for a Windows bug (all environments are running linux).

Uploading one of the problematic files through a non-uploadprogress form like the logo upload form works fine. (this isn't true, I mistakenly tested on the wrong server)

Oh, and... subscribe.

Sorry for the confusion in my earlier post. The file upload limits are set at /admin/settings/uploads. You must set these correctly for each role.

I have just encountered this issue when uploading an image through imagefield, using IE7 on new server

237KB file 2240x1905 px Fails

works fine on old server, so appears to be a server setting in my case if that helps. If i find out which will report back

i don't have anything called uploads in my settings. is this provided by a module or drupal core?

you cannot exceed the maximum limit of uploading the files

uploads is not in settings. it is in the mail account when u compose any mail then u want to attach any file then it is known as uploading of files

re#45
Not sure if this will help, but clues are good :)

I have found for my own issue I get a failure on one sever(the hosts latest), but OK on two others. I did notice on uploading a single image that although the error was reported and it didnt attach to the node, the file was on the server and functional

Guys, I am sure, this http 0 error is caused by firefox. I have verified it with their quality department. And was told to try out their pre release of 3.5.1. This version of Firefox solved all my problems with drupal.
Here is the link "http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/07/2009-07-15-04-mozilla-1.9.1/"

Also attached with this post is my chat log there at #quality channel on irc.mozilla.org

-Xyber.

It seems that we're dealing with multiple problems which have the same symptoms (the "HTTP 0 Error"):

1) Front-end:
A firefox plugin or some javascript code (like FCKEditor) is conflicting with the upload widget. This can be resolved temporarily by disabling the plugin or the javascript code in question. In the case of browser plug-ins, using a different browser is also a possibility. This problem should be replicatable on different servers running the same code.

2) Back-end:
Something on the server is causing the problem. This can be replicated on any browser (midkemia and I have both experienced this issue) and is related to various PHP limits (which can vary from server to server): upload_max_filesize, post_max_size, memory_limit (all three of these must be at least as big as the file you want to upload), and also max_execution_time must be as long as it takes for your file to be uploaded. This last point is what caused the issue for me and explains the wide variation of the critical file size that people have reported. This also explains why regular upload forms (like the logo upload form for the theme) are not affected (because in that case there's no background process running on the server)(this isn't true). I was even able to reproduce this issue locally with a big file and a very short max_execution_time.

re #51

Talking with my host, it appears it may be some obscure setting possibly in shPHP, that is different on their new server, still being investigated. Important point is i have seen the issue with a file of 300K

One odd thing has been encountered in that I have had an 800KB jpg file uploaded !

it looks pretty apparent that it is a server setting since many people can use the module without problem. it worked fine for me for months till the upgrade. anyway, i'm hoping that the module developers will have some idea what changed that i can use to go back to my sys admin with. i have no idea even what to ask since they will say images have been uploading fine the last few months. there is something specific about this release that needs to be added as system requirements. K

Ok update on #52 , My host has resolved my scenario of this issue

"RlimitMEM was set quite low which we only spotted having done a recompile of Apache and upgrade to PHP 5.2.10"

I have now been able to upload a 5MB file without issue, hope this means something to others

This is mostly definitely a javascript bug. Disable javascript on your browser and it works fine. With javascript enabled i get the error in any browser. If i disable javascript the uploads work. At this point, i have to turn off javascript everytime i want to upload an image. It's a real pain, but at least I've isolated the problem and upload an image when I need to.

more specifically, it is an ajax error.

I am having the same problem, I am getting HTTP 0 trying to upload files with IE8 or Opera 9.64, and HTTP 302 uploading with Firefox 3.0.12. The file will upload successfully though. Turning off Javascript makes the error go away, thanks for the tip. The uploads are for users, so I'm going to need to rethink some of my setup until there's a fix for this.

For anyone experiencing this problem, I don't get this error when changing the Progress Indicator to 'Throbbing' rather than 'Bar with Progress meter' on the field, so I am using that workaround for the time being.

Having the same problems...

• both in (some versions of) Safari and FF
• with 3.0 and 3.1
• no firefox add-ons
• memory limit high (90M)
• using small images (~25K)
• devel off
• no admin menu
• using mime type detection
• first, and any, user

...at a loss.

Ran into same problem... turning off ad-blocker fixed it for me.

Just learned that regardless of file size (in this case 90K) GD image toolkit will barf when the file is too large in terms of pixels.
It was a simple two color graphic, but it was 2500x1800px... 72 resolution. huh.

Anyway, looks like it was a filesize issue.

Just learned that regardless of file size (in this case 90K) GD image toolkit will barf when the file is too large in terms of pixels.
It was a simple two color graphic, but it was 2500x1800px... 72 resolution. huh.

Anyway, looks like it was a filesize issue.

Similar fix for me - reduced the pixel size and dpi and it was fine. Filesize irrelevant.

I don't have another image toolkit to test on.

Alan

What I've heard is that it takes 4 bytes of memory for every pixel (one byte for each channel: RGBA) when using GD, *just to read* the image. Then manipulations often require twice that to actually perform the action (such as rotate, where a second canvas needs to be created of the same size). So a 2800x1800 image needs:

2800x1800x4 = 20160000 bytes = 19.2 MB to read the image. Drupal itself generally takes about 16 MB just to execute the page, so that means you should have at 34+ MB in your PHP memory limit (not the upload limit) to generate the thumbnail. Usually I run my installations at 96 MB of memory just to be on the safe side when generating thumbnails, but perhaps even that isn't enough for scaling that large an image.

In the case I mentioned above with solution in #54, there was almost an instant timeout in some case. PHP Memory was set at 512MB !

This might be a solution: #547348: File is uploaded but not added to the field since access to filefield/ahah is denied (HTTP error 0)

It involves using CCK content permission and FileField.

Confirming #63 - I just uploaded a few different sizes of very simple images. And sure enough, it rejects the image past a certain resolution, even though the filesize is quite low.

I'm sure that anyone reading this has found the other threads related to this error - this might be kind of a stupid suggestion, but maybe the amount of javascript in filefield needs to be toned down? It seems like since we left the alphas, the number of posts to what was once a bizarre error (usually FCK-related) have grown exponentially - everything from Firefox addons to PECL to GD2 to different memory limits to browser versions to etc. etc....

So, maybe the problem is really in filefield -- that some elegance has been lost in improving functionality?

Just a suggestion.

I'm using FF3.5.2 and uploading does not work for me.
On the same site, it's possible to upload from another pc with firefox 3.0.13, both pc's running ubuntu 9.0.4

Ascertaining that it is a random and in my humble opionion retarded problem is the only i thing can do as a drupalnoob.

Just browsed my ftps and it seems, that all the files got uploaded and named correctly. This leads me to the conclusion that the problem has to do with the function/site/whatever opened on confirm/submit.

subscribing

It seems that disabling "Linkification" solves my problems.
@Everyone: Try a clean firefoxinstallation.

Not using firefox, same problem
Subscribing

Had the same problem, but now fixed:

2 reasons:
- The php_value upload_max_filesize value in the .htaccess or .config file, should be set to higher..
- The max_execution_time value in the php.ini file should be set to higher (it causes server time out...)

Good luck

I was experiencing this problem with all image types, and I traced the problem to a wrongly typed variable in a call to the jQuery attr function from jquery.form.js. I couldn't find an unpacked version of jQuery Form 2.01, so I'm not entirely sure what the problem is there, but what I do know is that upgrading to the most recent version of jQuery Form (currently 2.32) solved the problem for me.

This error occurred for me in Chrome, no matter what user I am logged in with, but not in Firefox 3.5. (PS - Ubuntu).

I upgraded to the latest jquery.form.js (2.33 at the time of this comment), and now it works in Chrome, but the page refresh is "funky." Any form fields that are required but not filled in at the time of the upload generate error messages.

2.33 also breaks Wysiwyg's javascript, unless JS aggregation is disabled in admin/settings/performance.

So my temporary fix is upgrading to jquery.form.js v2.33 and disabling javascript aggregation.

UPDATE: After (finally!) succeeding in installing PECL Uploadprogress, the error has returned.

This error is not server related. I've recently migrated to a different server using the latest cutting-edge LAMP technologies and the error is still there. Again, this is a jquery/javascript error. If you turn off your browser's javascript the upload works fine. The module is buggy at this point.

Erm... Ok, just want to update. I noticed that whenever i am using hotspotshield, all drupal sites will produce this problem. So you might want to take note. Just disable it for a bit and see.

-Xyber.

Memory limit at 128M and with Opera 10 Fails, with Firefox 3.5.3 OK

PECL not installed

Had the same problem, but now fixed:

The tmp directory that is used by mysql (not the tmp directory of drupal) on the webserver had no space left any more.

I have 14MB free in the hosting

Check if you have in phpinfo upload_tmp_dir set. On my host server default value was empty. Just change it in php.ini to /tmp.

I have no access to php.ini file...

Similar problem with Javascript only in Opera 10. In Firefox 3.5.3, Chrome 3.0.195.27 and (sic!) IE6 - upload is working.
Error: An HTTP error 0 occurred. mysite.com/filefield/ahah/story/field_img_story/0
And when I checked "Stop executing scripts on this page" - it works even with Opera.

I'm curious if anyone else has UNI-8 problems that has this problem? for example

* 1
* 2
* 3
* next ›
* last »

Whenever pager is called? This problem cropped up for me around the same time.. I also noticed some UNICODE javascript and wonder if perhaps their's a sterilization problem somewhere?

unicode problem hit me with d6.14 at the same time the javascript error cropped up..

I origonaly thought this was new modules on a site but a site that remained static till an upgrade to drupal-6.14 it happend I also get an database update error however everything looked fine (for a while) I'm thinking the cache was the real reason it looked ok and not that it was another module..

focusing around UTF8,

During the writing of this I put in zend with localization,

tried http://teqsnacks.com/2007/04/27/drupal-change-db-and-table-collation-to-...
which failed
so I went into phpmyadmin (which their javascript was broken in much the same way) and changed all the tables to UTF-8

and tryed http://serverfault.com/questions/54911/debian-how-to-convert-filesystem-...

removing and reinstalling locales and doing a dpkg-reconfigure though is what seems to have fixed it for me.. I have no clue how my locales changed on me however.. or why it all of a sudden cropped up after a d6.14 upgrade, if it was related to that at all.

Is there a way to check users locales? short of looking at the pager? Their's no way one of the drupal modules like transliteration would change a users localization right, or translate?

Anyhow hope this helps, or inspires someone smarter than I.

Like someone else I'm getting this in Opera 10, but not FF3.5

Then I get redirected to upload/js containing this:

{ "status": true, "data": "\x3ctable id=\"upload-attachments\" class=\"sticky-enabled\"\x3e\n \x3cthead\x3e\x3ctr\x3e\x3cth\x3e\x3c/th\x3e\x3cth\x3eRadera\x3c/th\x3e\x3cth\x3eLista\x3c/th\x3e\x3cth\x3eBeskrivning\x3c/th\x3e\x3cth\x3eVikt\x3c/th\x3e\x3cth\x3eStorlek\x3c/th\x3e \x3c/tr\x3e\x3c/thead\x3e\n\x3ctbody\x3e\n \x3ctr class=\"draggable odd\"\x3e\x3ctd\x3e\x3c/td\x3e\x3ctd\x3e\x3cdiv class=\"form-item\" id=\"edit-files-14-remove-wrapper\"\x3e\n \x3cinput type=\"checkbox\" name=\"files[14][remove]\" id=\"edit-files-14-remove\" value=\"1\" class=\"form-checkbox\" /\x3e\n\x3c/div\x3e\n\x3c/td\x3e\x3ctd\x3e\x3cdiv class=\"form-item\" id=\"edit-files-14-list-wrapper\"\x3e\n \x3cinput type=\"checkbox\" name=\"files[14][list]\" id=\"edit-files-14-list\" value=\"1\" checked=\"checked\" class=\"form-checkbox\" /\x3e\n\x3c/div\x3e\n\x3c/td\x3e\x3ctd\x3e\x3cdiv class=\"form-item\" id=\"edit-files-14-description-wrapper\"\x3e\n \x3cinput type=\"text\" maxlength=\"256\" name=\"files[14][description]\" id=\"edit-files-14-description\" size=\"60\" value=\"Överblick hemsidan.doc\" class=\"form-text\" /\x3e\n \x3cdiv class=\"description\"\x3e\x3csmall\x3ehttp://drupal/sites/default/files/Överblick hemsidan_0.doc\x3c/small\x3e\x3c/div\x3e\n\x3c/div\x3e\n\x3c/td\x3e\x3ctd\x3e\x3cdiv class=\"form-item\" id=\"edit-files-14-weight-wrapper\"\x3e\n \x3cselect name=\"files[14][weight]\" class=\"form-select upload-weight\" id=\"edit-files-14-weight\" \x3e\x3coption value=\"-1\"\x3e-1\x3c/option\x3e\x3coption value=\"0\" selected=\"selected\"\x3e0\x3c/option\x3e\x3coption value=\"1\"\x3e1\x3c/option\x3e\x3c/select\x3e\n\x3c/div\x3e\n\x3c/td\x3e\x3ctd\x3e264 kB\x3c/td\x3e \x3c/tr\x3e\n\x3c/tbody\x3e\n\x3c/table\x3e\n\x3cdiv class=\"form-item\" id=\"edit-upload-wrapper\"\x3e\n \x3clabel for=\"edit-upload\"\x3eBifoga en ny fil: \x3c/label\x3e\n \x3cinput type=\"file\" name=\"files[upload]\" class=\"form-file\" id=\"edit-upload\" size=\"40\" /\x3e\n\n \x3cdiv class=\"description\"\x3eDen maximala uppladdningsstorleken är \x3cem\x3e1 MB\x3c/em\x3e. Endast filer med följande filändelser kan laddas upp: \x3cem\x3ejpg jpeg gif png txt doc xls pdf ppt pps odt ods odp\x3c/em\x3e. \x3c/div\x3e\n\x3c/div\x3e\n\x3cinput type=\"submit\" name=\"attach\" id=\"edit-attach\" value=\"Bifoga\" class=\"form-submit\" /\x3e\n" }

Sorry, it's swedish.

fridaythe14th ;

That looks exactly like the errors I was getting

http 0 when clicking an Ajax link, and after submitting that, a big wad of text.

If you have shell access try typing:
locals

and verify your using a UTF-8/derivative format and not an ISO-*

If you are try "locals C" to fix or reconfigure/remove/reinstall I had little sucess reconfiguring it and it generated tuns of problems till I remove/reinstalled but that's for another forum, and I'm not smart enough in multilingual setups to offer proper or even safe guidance. (do the previous at your own risk)

Seeing what it says, I'd be willing to bet a majority of the problem is server languages not being UTF-8, as is required by drupal. I know their's suppose to be a check on the database on 6.x for proper database language format of utf-8 however mine were all in Swedish as my above post states (in cryptic sleepless-ez).

Accented characters will render improperly see: http://drupal.org/node/349508

http://www.google.com/search?q=drupal+utf+8+site%3Adrupal.org&ie=utf-8

an example of it's impact in drupal 7 http://drupal.org/node/371495

perhaps 6 suffers from it and this is just the most visible affliction of it?

I'm still suffering problems with views on occasion. It would be grate if someone had a link to how to properly fix that problem on *nix for all us 1man armies who could use the instruction & test that route?

I had this error whenever uploading images larger than 1 MB to a node via image field. Tried disabling firefox add-ons and updating jquery.form.js with no luck. My hosting provider gave me access to a php.ini file that I could edit, I bumped:

memory_limit = 32M  ; Maximum amount of memory a script may consume (32MB)

to 64 and that resolved it.

I'm having this problem too. I click browse choose a file to upload (not imagefield) click add another file and then I get the error. Here is a photo so people can see what's going on. For the time being people can now only upload two files but there is a bug in the AHAH

Seems like everyone is stabbing in the dark with this problem. Can't say my post is going to help, but this seems to be an issue that enough people post, maybe a solution will gracefully appear from the chaos...

What Worked

Disabling JavaScript definitely works - but not really a great solution
Granting permissions in content_permissions module > edit %field_name (for upload field) to user/role - this works (with JS enabled). Not sure of other security implications, but have enabled it for all CCK filefields for practically all authorized roles, and just keeping things tight with user create/edit permissions in node module. For some reason the content_permissions fix for this issue does not work in the context of OG User Roles.

What Didn't

Changing the PECL uploader from a bar to a throbber - no effect
Increasing PHP memory resources - live server at 128MB (increasing no effect); dev server at 512MB (should I really need any more?) - no effect at all
PHP upload_tmp_dir setting - no effect
Switching browser - no effect. Problems noted in FF, Safari and IE

I am having this problem with the ed_classified module. I stopped allowing unlimited number of files upload and limited to two uploads one for a resume and one for a photo. It works perfect now. In the reports system status menu it says that it can't find PECL binaries which are installed if that has anything so do with it.

snorkers: What about to increase PHP max_execution_time and max_input_time settings ?

Had already set time settings to 240sec on the DEV machine and problems were still there. (On live, have left them at 60s - which is probably way OTT)

This may be helpful for someone so I'll throw it out there!

I was having this issue with filefield (using it as a file upload field). I realized my problem was that the only file extension i was allowing was .txt files... which is the default. Make sure you account for all the file types you will be uploading by editing the field and adding them to the allowed extensions box :)

Wow this is a painful read. My server is 4' 20" off the ground, my cat is 30% longer than other cats and i too am having this problem.

I got the HTTP 0 error a few times... but got distracted by the json data dump i see after a file upload. I'm reporting it here because others have posted the same error as well. Updating jquery.form fixed this particular problem. I'm not sure if it is related to the HTTP 0 or not yet. I'll report back if i think so.

This happened in Chome (mac) and safari, not in firefox. I updated jquery.form using the http://drupal.org/project/jquery_form_update (uses jquery.form 2.16) and http://drupal.org/project/jsalter modules and that fixed my json dump error after load.

Hey folks,

Here's our problem - files upload - appear in the file system and are fully useable, and are entered into the files tables as temporary - but they do not attach to the node and they generate an http error 0 during the upload.

I ran firephp on the upload event, and got this php error as a response, accompanying the js alert:

Fatal error: Call to undefined function filefield_file_listed() in /.../drupal-6.14/sites/all/themes/cdhal/template.php on line 174

Which is really really interesting because our admin theme is garland.

The http error 0 alert is generated by a drupal.js function (Drupal.ahahError)

#93 resolved by removing a function from our template.php in our custom theme.

Here is the problem function:

I receive error while loading image file:

"413 Request Entity Too Large
nginx/0.8.21"

May be changing client_max_body_size property in nginx.conf may fix problem