HTTP 0 error when uploading ANY file

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.

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

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.

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.

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 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

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-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.

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

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.

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.

{ "status": true, "data": "\x3cdiv  id=\"edit-field-profile-resume-0-ahah-wrapper\"\x3e\x3cdiv class=\"form-item\" id=\"edit-field-profile-resume-0-wrapper\"\x3e\n \x3clabel for=\"edit-field-profile-resume-0\"\x3eResume: \x3c/label\x3e\n \x3cdiv class=\"filefield-element clear-block\"\x3e\x3cdiv class=\"widget-preview\"\x3e\x3cdiv class=\"filefield-file-info\"\x3e\x3cdiv class=\"filename\"\x3e\x3cdiv class=\"filefield-file clear-block\"\x3e\x3cdiv class=\"filefield-icon fiel ...

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:

/**
 * Source: http://drupal.org/node/304930#comment-1053227
 * Theme function for the 'generic' single file formatter. Added Filesize.
 */
function phptemplate_filefield_file($file) {
  if (filefield_view_access($field['field_name']) && filefield_file_listed($file, $field) && ($file['filesize'] != 0)) {
    $path = $file['filepath'];
    $url = file_create_url($path);
    $icon = theme('filefield_icon', $file);
    //drupal_set_message("<pre>".print_r($file,TRUE)."</pre>");
    return '<div class="filefield-file clear-block">'. $icon . l($file['filename'], $url) . ' <span="filefield file-size">' . '(' . format_size($file['filesize']) . ')' .'</span>' .'</div>';
  }
}

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

I have this problem too, in my case the culprit seems to be memcache. Disabling it solves it.

Adding my situation to the long list here.

I am duplicating the functionality of securepages through rewrites. I use rewrites to send node/add and node/*/edit to https. I had to add upload/js to that list so the js upload was going to the same scheme. Otherwise I was getting this error message.

This happens with the securepages module as well: http://drupal.org/node/82015.

What the last filefield worked version was? I would like to downgrade.

Using Video 6.x-3.2 and Filefield 6.x-3.2

I got the "An unrecoverable error occurred. This form was missing from the server cache. Try reloading the page and submitting again." error and tried the Suhosin settings in php.ini in my root from the previous thread: http://drupal.org/node/539476#comment-1886662

After reloading and trying a couple of times, I was able to upload the video files. I do not know what decided the failure or success.

subscribing

I hope my post can be of help, since I managed (somehow) to solve the HTTP Error 0 issue.

The initial situation:
—LAMP server, with PHP memory limit set at 128M;
—multisite Drupal 6 installation, with FileField and ImageField active on most sites. However, I received the error only on one of these websites (so it obviously had nothing to do with the server or other flaws in the Drupal installation of module code);
—no devel modules active on that specific site;
—no FCKeditor. There was, however, WYSIWYG active: the error was still there after I disabled it;
—error received on all browsers;
—when I disabled JavaScript on Safari I didn't receive any errors, but the form returned an empty page.

After trying everything, and disabled all modules that had something to do with Javascript (including Javascript tools and Activemenu), the error was still there. I then decided to do something radical, and disabled and uninstalled both ImageField and FileField. If you do this, remember to back up your database and files directory.

I thought this would erase stuff from the database and the file system, but it didn't. The "Manage fields" page of the content types that had image fields attached warned me that the fields were still there, but were disabled because the relevant modules were disabled.

I re-enabled both FileField and ImageField, and everything was still in place: data, content-type and field settings, etc. With the added bonus that uploading images is now working again.

@#101

since I experience the problem intermittently, it is difficult to determine the cause and the cure

reinstalling the ImageField and Filefield modules might fix it - or have no effect at all, you may just be getting a run of intermittent successes

today I was uploading video files to debug the Video module - I got the http 0 error a couple of times, was successful more often, uploading the same file

my gut instinct is that it is a server setting and/or timeout, so it is difficult to fix it with code

Same problem form me with Opera 10.10 Stable (Http error 0) with screen result described in post: #83

No text-editor or devel installed.

I change the coding to UTF-8 in browser but nothing changes.

Even very small file are affected.

With Opera 9.65 and Firefox 3.5 all works fine.

... ideas to solve?

subscribing (I am having the same issue with Video Upload module) Small files upload but large do not.

@decibel.places #102

my gut instinct is that it is a server setting and/or timeout, so it is difficult to fix it with code

In my case I don't think it's a server issue, since I have 15 sites running on the same installation of Drupal 6, many of which use FileField and ImageField without any kind of trouble whatsoever. I guess it's something that went wrong in a recent update and that was fixed doing what I said I did in #101. But again, since I can't explain what was wrong, I can't explain how it got fixed.

subscribe

Subscribe.

subscribe

subscribe

Hi All,

I am having very similar problems with file uploads. I am running the latest filefield/imagefield modules with the latest pressflow install. The difference in my problem from the rest is that I can upload images/files without issue if accessing the site from the host (i.e. http://hostname/site/data). As soon as I switch to using the full domain name (http://hostname.mydomain.com or http://www.mysite.com), the filefield/imagefield uploads fail with http error 0 instantly. The files (and thumbnails where appropriate) all make it to the correct locations on the filesystem but do not attach to the page. I am using only sites/default and a single database as all of these requests should return the same site. I have no base_url set in my settings.php.

I have tried all variations of the solutions in the forums including, updating various jquery js files, adding and removing modules that would offend, devel turned off, no cacheing whatsoever, memcache is not installed (so no problems separating the bins), increasing max image size, memory settings and the like.

For me, this feels like a rewrite issue (since it works using the hostname without a domain), but I have the simplest rewrite rules in place. I only changed rewritebase to reflect the path to the site (even changing it to / does not work).

Any ideas? I feel like I'm missing something basic in my configuration, but even with all the logging turned on, I don't see anything that would be causing this error. I turned off javascript (in drupal.js by setting the jsEnabled variable to false) but this did not work. Interestingly tho, I misspelled true when re-enabling this - essential breaking the variable - and js was broken. This works, but the page reloads to load the image (and is probably bad because it might produce unexpected results). But I don't think this is a good work around.

Thanks!

Our problem is fixed.

http://drupal.org/node/297035 #102 had our solution. Apparently we had some custom modules that set the document.domain in javascript. This confused the iframe that does the upload of the file. In our case the code (we wrote) that set the document domain either broke with hostnames without domains, or handled that situation. So we got the weird behavior I described in my other post.

Make sure you've transfered "image.imagemagick.inc" from sites/all/modules/images to includes/. That did the trick for me...

I too have been plagued by this problem. It all started when I wanted to add Video, using the Video Upload module, to our site. After extensive testing I have narrowed the problem area down. At least in my installation. The error isn't restricted to the Video Upload module because I can use just a File Field and have the same issue with the same file.

I currently have my Max File Upload and Max Post settings set to 50M and the Max Memory set to 128M (have gone so far as setting these to 500M each). Then I set the PHP Upload Tmp Dir to a folder I could monitor. I can successfully upload any file up to and including 28MB. When I upload a file up to 28MB a temp file is created in the Upload tmp dir. Attempting to upload a file larger than 28MB returns the HTTP 0 Error. Also, when attempting to upload a file that causes the HTTP 0 Error no temp file is created in the Upload tmp dir, even though the browser indicates a file is being uploaded. This indicates to me that the problem might be in the javascript. Afterall, if the browser acts like an upload is occurring but the server doesn't show any uploads (no temp file) then wouldn't this mean the problem lies in the client script?

More research done...

So, I found the major cause was server side after all. IIS 7 imposes it's own post data limit of around 30MB. Once I figured that out and changed it the error went away. For anyone else experiencing an upload limitation and is running IIS 7. Look at this http://www.cyprich.com/2008/06/19/fixing-file-upload-size-limit-in-iis-7/.

New issue, same result. If I'm using a slow data rate the upload times out resulting in the Error 0. Is the time out caused by IIS or PHP?

Final note...

The time out error was also caused by IIS.

I have a linux server, I have shell access, I used imagecache, filefield, imageapi. I have php memory_limit at 96M. I installed the PECL upload progress. I did all this on the same shared server for two sites, one site is working fine- no ahah error while I'm at work on my dual-core iMac (snow leopard), the other I'm trying to upload pictures to at home, on an old g4 with tiger - mac os on both, settings duplicated. One works, the other gives me "An HTTP error 0 occurred. /filefield/ahah/photo/field_photo/0" - is it a network setting? os performance? ram?

also, I used safari and firefox.

subscribe

Works fine with firefox, chrome. The error occurs in IE (8 and 7 comp).
Just on one site on a multisite environment with custom theme.

For our list of duplicates: http://drupal.org/project/issues/search?issue_tags=ajax%20upload%20problem

I am seeing this too for the first time (since doing something post recent updates). Fortunately at the moment, I briefly see a red HTTP 0 error message in-line near the upload image field field, then it disappears and the file uploads. No entries have been found so far in either the Drupal or server logs. I can live with this as long as things work. But I know as this site transitions to client use, it will confuse/worry them.

Will monitor and do some more testing. But there is obviously new behavior following recent updates. No other server configuration changes have been made that I am aware of since the time when it was working without issue.

--Sohodojo Jim--

subscribe

Hi, I'd like to share my experience around this problem.

I had used this module for various customers and never had such problem until now as I'm releasing a big portal that is a blog and also a social network.

I had tried some of the things mentioned above and none of them worked. I had problems with any browser of any kind.

The more relevant test I had done and that worked was changing my internet connection.

I have an ADSL "low-band" (1MBps) connection, and that the company also restricts the upload rate to about 15kBps. And I have a 3G modem, 7.2Mbps, that have upload peaks of 45kBps. The tests were done with the same computer and the same Drupal system, in the same hosting service.

• Using ADSL: Let's say that 1 in each 4 attempts give me error. Trying to send various files through "add more one item" button always gave me error.
• Using the 3G: Worked very well all the times. I could even send 5 files at time with the "add more one item" button, and had done this several times (I haven't done tests with more files per time yet).

What I conclude about my experience joining from what I read in the related issues: It's stronger that the error is happening because there is some error or misconfiguration in the way that js/ahah/js-form/jquery treat file uploads, but I think that is mainly about timeout (because there is such difference in the upload speed in my experience).

Thanks for attention!

Just wanted to add my 2 cents to this... Hopefully it helps others.

I noticed some of you have already mentioned the uploadprogress extension of PHP... And if you don't need it that desperately (which in my case I don't), then disabling it seemed to fix my problem :)

To disable simply click the WAMP icon in the taskbar
Click PHP > PHP Extensions
Navigate to php_uploadprogress and if it's already ticked, click it
Your webserver should restart, hopefully fixing the problem

It worked for me... Might as well give it a shot :)

If disabling it is not an option for you, then perhaps look into different versions of it? Either way, it seems that this is (one of) the cause(s) of the problem!

This may or may not be related to the occasional banning of an IP address by Drupal infrastructure, normally due to unusual activity or too many HTTP requests

Does updates.drupal.org IP 140.211.166.6 (master.drupal.org) block suspect IPs?

I think that during the period of my earlier posts on this thread I was banned on only one node of d.o.

I fixed it for my problem, which was uploading images, I was getting the HTTP 0 error. What I did to fix it - messy, I know but it worked! :)

Commented out the following code:

'#ahah' => array( // with JavaScript
'path' => 'filefield/ahah/'. $element['#type_name'] .'/'. $element['#field_name'] .'/'. $element['#delta'],
'wrapper' => $element['#id'] .'-ahah-wrapper',
'method' => 'replace',
'effect' => 'fade',
),

in the filefield_widget.inc file.

++

Not sure if this is helpful, but disabling JavaScript seems to work for me (Safari 5 / OS X).

subscribing

You are right: it was devel module: http://drupal.org/node/888238

Thanks a lot :-)

My last comment was a reply to #33 comment (http://drupal.org/node/473760#comment-1797236) from quicksketch

just want to add another potential cause / troubleshouting hint: apaches mod_security enabled and a "wrong" setting for SecRequestBodyLimit can also cause the error - so if nothing helps one might try increasing the value here.

I have memory of 512M and have this problem after enabled several modules and configured them. I am not sure which one had made the problem. But I tried to uninstall them without solving the problem. Finally, I hack the file field module by comment out the ahah definition in filefiled_widget.inc.

Modules that i had installed are:-
Menu Settings per Content Type
Fromfilter
Node Form Settings
Editable field
ajax load

hello all, i am also having this issue and eagerly awaiting discovering a fix. could someone please advise me as to which PHP estensions i should ask my host to turn off? i'd like to ask, despite if anyone thinks it is impossible. uploading files is of utmost importance to my users right now and i need figure this one out. thanks!

i was able to comment out the code in filefield_widget.inc as a temporary fix. :)

I can confirm that the commenting of the code snippet in filefield_widget.inc fixes this problem. I commented it and my images uploaded without a problem. Dont know what the problem was, dont care. Not enough time to spend figuring it out. This should be fixed though as it's pretty much a show stopper for filefield. It should stay marked as critical until fixed. TY for the temp fix @122 (califken), nice work tracking it down.

As for my two cents: I had this happen only on my live site, which the only difference from it and the test site is the use of Secure Pages. I suspect that the fact that I am editing the node via https is giving me a similar error code.

Edit: Never mind, the fix for this was a bit too obvious for me. #82015-8: securepages conflicts with file upload

In my Drupal setup (Drupal 6.17, FileField 3.2, ImageField 3.2, PECL upload progress) I had had this problem with Safari and Chrome.
I fixed it commented out the following code in filefield_widget.inc

'effect' => 'fade' at line 290

'effect' => 'fade' at line 311

I solved this problem by replacing my .htaccess from the latest (drupal 6.19) release. Nothing else worked!

I have a very strange version of this problem, and I tried every fix mentioned in this discussion. None worked.

My issue is I have two Image-based custom content types. Both of them could upload just fine. Then, without any updates or changes to the system at all, suddenly one of the custom content types gets this error when I upload the image, but no other content types get the problem. The other custom image type is IDENTICAL to the one that doesn't work, except for a few key meaningless differences (the machine names of the contents and fields and which Views pages display them).

Besides the fixes mentioned here, I've also tried reinstalling FileField, messing with folder permissions, and recreating that content type over and over. It seems every content type that I make after this problem showed up has the problem.

I was experiencing the same issue, I also have memcache installed. Memcached displays statistics on the bottom of everypage, I noticed in the firebug net stats that filefields ajax response was resturning the memcached data again. I turned it off and then everything was fine. I will posting this a bug report to memcache.

Hello

I`ve had the same problem with all of my drupal installations. After some investigation i`ve found a solution, and it looks like the problem is host side.

What i did was naming "Temporary directory" (admin/settings/file-system) to "tmp" and created "tmp" folder in drupal root. Hope that it helps someone.

Hi to all.
In ref. to the infamous HTTP error 0 while trying to upload files/images.
Just posting some test setups i run, hoping this will enlighten the wise people out there..
1. I get the same problem with FileField 6.x-3.7, Node Images 6.x-2.1 and Node Gallery 6.x-2.0b2 (all are current versions).. when it works, it works with all the modules. From this, i conclude it's NOT module dependent.
2. I get the problem with different Java JREs : 6.0.210 AND 6.0.220 <-- latest version, WinXP and Seven.
3. The following browsers work fine : IE 8.0.6001/8.0.7600.
4. Firefox 3.6.12 fails, with JRE 210 and 220.
5. Firefox 3.6.6 and 4.0.b7 works fine, with Java 210 and 220.
6. In Ubuntu 10.10 , FF 3.6.10. Java 1.6, it works fine.. But thats Linux :)
All the above were tested on the same Drupal 6.19 server on WinXP and XAMPP 1.7.3, on a LAN.

My conclusion is that this is a Browser+java implementation dependency, not a module issue, but maybe a Drupal core compatibility issue ?

It'd be very strange for Java to have anything to do with this problem. JavaScript is in no way related to the Java runtime installed and FileField (and Drupal core) doesn't use Java at all.

I tried with the latest Firefox and Chrome.

I cannot believe that it works fine under IE 8.

If the files are small: 100KB or similar, any browser works fine. Under bigger files I got the js error, except with Internet Explorer 8 as I said.

I recently encountered this problem when moving a site from one system to another. Uploads worked fine on the system I was moving from, but not on the system I was moving to. The problem turned out to be that the system I was moving from had "/tmp" in the list of valid open_basedir values found in an apache configuration file:

php_admin_value open_basedir "/var/www/somedirectory/httpdocs:/var/www/drupal:/tmp"

When I moved the site, I omitted the "/tmp" directory from open_basedir setting, thinking it was unnecessary. That turned out to be a mistake, since the php argument upload_tmp_dir was not set, and apparently defaults to /tmp (according to some sites). In any case, adding "/tmp" to the open_basedir settings fixed the problem for me.

It seems unlikely this bit of information would be of much use to those experiencing this problem in relation to file size or browser, but it might help someone.

This problem is maybe caused by a wrong configuration of $base_url and should be prevented by inserting a warning message to the requirements system. Therefore I created a new issue #1046682: Install/Update process fails if $base_url is set to a wrong URL. Please close this bug as a duplicate, if this solves your issue. Thanks!

I have this problem again with last 3.9 version and with browser Opera (last update 11.01).

I have 128 MB of memory in a dedicated server with: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch13

I use the modules with:

filefield image (no problem here)
filefield path

Any ideas?

FYI to people coding, and getting the http 0 error, you will get this during the ahah (js file upload) process, if the ahah url doesn't return any valid return. This can also happen on a number of cases:

- you have a php error;
- your http return is empty (you did a die.)

You may run into this case if you're extending the module.

I solved in a strange way but I did!

Please, take a look at this:

http://drupal.org/node/491610#comment-4260902

Hum, I swear I thought we only had one of these issues (as I would like it). No point in having two discussions: #297035: HTTP error 0

Please do not reopen.

Solved!!
I have an error on plesk panel
http://forum.parallels.com/showthread.php?t=112735
thanks to www.abserhosting.com/

HURRAY...I Got It....

I installed the jquery update module and its fixed.

Install the jquery update from:
http://drupal.org/project/jquery_update

I too struggled with this error and found that the memcache statistics be rendered in the footer of my site was the problem. Once I unchecked "Show memcache statistics at the bottom of each page" and flushed the cache, fieldfield started working again (http://yoursite.com/admin/settings/memcache). So my advise to you is too look for modules that may be in conflict after you've eliminated all the file size constraints in PHP, Apache and Drupal.

That's my two cents, take it for what it's worth. Hopefully it was helpful.