'HTTP error 0 occurred' on image upload

Likely caused by similar problems as #356009: Large Uploads Cause Form to Disappear.

The key thing from that giant error is, "The file in the image field was unable to be uploaded." This happens when FileField is completely unable to save the file. How big are the images that you're uploading? If they exceed the maximum post size, you'll run into a world of troubles. See the handbook page on increasing the upload size: http://drupal.org/node/422474

Thanks a lot for a quick reply, quicksketch :)

You were right - the problem is with all uploads - I tried different files as small as 10Kb and still got the same response.

I cannot make changes in php.ini on my host (I don't even have ssh access to it :/ ) and improving .htaccess didn't give any results nor updating jquery.form.js
I studied all the support issues on this matter I could easily find and none of the solutions apply.

No changes at host possible.
jquery.form.js - updated
permissions are - OK
max upload size - SET

To tell you the truth I'm out of ideas.

I have the same problems, but it happens only randomly. The only way I could reproduce it is with 1Mb size pictures, and only 1 of 6-7 generate the HTTP 0 error.

I've already tried : increased PHP memory, several filefield/imagefield version

On the server side, I get a "connection reset by peer mod_fcgid cannot get data from http client"

I'm also almost out of ideas, but will give it another try tomorrow.

I've already tried : increased PHP memory, several filefield/imagefield version

Could you clarify "increased PHP memory"? The key thing is that you increase the "post_max_size" and "upload_max_size" settings (as per http://drupal.org/node/422474). Can you upload the same files successfully using the core Upload module?

post_max_size : 32Mb
upload_max_size : 24Mb

The image I use to reproduce the bug is ~1Mb, so this should be ok.
By the way, I also tried to update jquery.form.js

Currently reproducing is very hard.
- On one computer, I can reproduce it in IE7 (as I said, it fails every 7 uploads) but never with Firefox.
- On another computer, I cannot generate the error at all (with same OS, same Browser, same file to upload, following exactly the same steps).

This is very confusing ... I'll do more tests to try to isolate all possible causes before continuing this discussion.

But of course any suggestion is welcome.

Hi again.
Just checked my hosts php.ini and here is what i found:

upload_max_filesize local value:64M master value:64M
upload_tmp_dir local value: no value master value: no value

does it change anything that the upload_tmp_dir is not set? does drupal handle it somehow?
and if the php.ini settings aren't the cause of the file upload error - do you have any idea what might be?

thanks in advance!

flamik, it's also important to check the post_max_size value, since the upload_max_size is inherently capped by post_max_size, however if your upload_max_size is already at 64M, it sounds like your host is smart enough to increase the default values. I'm a little at a loss why uploads wouldn't work at all. Perhaps try setting up a completely empty Drupal site, just to see if you can use upload.module right out of the box.

I'm moving this to a support request until we can determine if there's something FileField can do to fix this problem, since flamik reports the problem also exists for normal uploads using upload.module.

flamik, I didn't answer your question about tmp folders. Drupal should automatically set a tmp directory for you, but it would help to just confirm that it is setup and working for you, visit admin/settings/file-system, and make sure that the tmp directory is set and you can write to that directory. Some times it'll help to put this temp directory inside your home folder if you're on a shared hosting server. Also, you should check the Drupal logs at admin/reports/dblog to see if errors are being thrown (FileField logs a lot of errors that aren't shown directly on the page).

Some news ...

- This problem does not appear with FileField
- I've set up a "clean" Drupal installation (no modules except CCK, FileField, ImageField) on the same server
to retest everything.
- All modules are up-to-date

When I upload a medium-sized image (~1Mb) I get randomly (1 of 5 times) :
with Firefox : the imagefield section disapear
with IE7 : I get a HTTP 0 error

There are other issues that seem related and I've tried any suggested proposition that I found without success.

I'd be happy to do more tests, but I'm a bit out of ideas.

Marked #443684: Cannot upload an Image of a certain Type as duplicate.

I get the same issue only in Firefox. The upload works fine in IE 7. I've tried updating jquery.form.js; I've set the max upload size; I've set the max resolution for images; I've check the memory_limit in php.ini and it was already set to 128M. The permissions are set... I don't know what else to look for. In Firefox, the error is random; the upload seems to work once every 10-15 or so tries.

The module is also up-to-date. I just installed it 3 days ago.

Any more ideas?

I have the same error however not the same causes.

post_max_size, upload_max_filesize, memory_limit are all up over 100M

I did not have this problem with RC1, I am not having it with fields created with RC1, however creating an image field in 3.0, then trying to use it outputs this same error. The biggest file I tested this was was 58kb.

*Edit*

The paths are created and the file does get saved, however this is still a big problem as it still errors on form submit when you go to save your content.

tested FileField, preforms as expected, this is isolated to ImageField

*edit*

Ok this problem only seems to appear with the progress meter on, throbber works as expected

I'm refusing to accept this as a bug report unless instructions can be provided to reproduce this problem from a fresh installation of Drupal.

@rtbox, In your situation, does uploading through the core upload.module work any better?

@quicksketch, core upload works as expected, as per my edit above, this seems to be isolated to the progress meter in imagefield only.

Oh, interesting. Perhaps the AJAX requests are not being handled properly. rtbox, you said that you recently upgraded, did you clear your caches after upgrading? FileField registers a new menu handler for the progress bar, if the menu cache hasn't been rebuilt Drupal won't handle it properly.

just tried clearing my cache, no go, besides the progress bar functions correctly with a filefield, just not an imagefield.

attempting to recreate now.

ok, I just got it to work somehow, clearing the cache did not make the field I had already created work, however after deleting that field, and recreating it, it worked (had done this before the clear and it did not change anything).

Is there a possibility that the cleared cache did this? I have been fiddling with other stuff to see if I can get it to fix, such as disabling different modules, etc, so I'm not sure if it was the cache or a module conflict.

ok spoke a little too soon, still no luck in reproducing the problem from a fresh install, but it seems if I create the imagefield with upload.module disabled, i get this problem. If it is enabled I do not.

It does not function like this on a fresh install, i will continue trying to figure out how to reproduce.

Thanks rtbox, I appreciate your sleuthing!

Ok....... well i've started getting a different error now -as well as the original one-, the problem seems to crop up randomly on creation, if it is created with the problem, the field always has the problem.

This is the new error I get:

The instruction at "0x0077acb9" referenced memory at "0x37396170". The memory could not be "read".

with this it crashes my httpd

am having trouble recreating, i managed to get it to do it on a fresh installation but after installing the modules from my production site. still thinking it may be a conflict with one of those modules, but it's possible it's standalone and it just wasn't doing it before.

- oh, and occasionally i get this error message under the upload box:

An HTTP error 0 occurred. /filefield/progress/a2ba6c389ccba62244455b3fb7807ad9

I'm having the same issue as sra1 in comment #12 -- This happens only in Firefox (3.0.10) on Vista, not in IE7. This in on Drupal 6.10.

If I wanted to downgrade to a previous version of imagefield to see if that helps at all, am I going to have problems because of db changes?

@aasarava if you mean from 3.0->3.0RC1 then there were no DB changes so you should be able to do it safely.

@quicksketch no luck at all with isolating the problem, I might give this a try again next week, however, I need to push ahead with the project so I will just be using Throbber for now.

Note: I'm downgrading the priority since we can just use Throbber on the occasion that this issue does crop up.

Thanks, rtbox. Actually, please don't lower the priority. It's still critical! On further testing, this problem crops up for me randomly on both Firefox and IE7 -- and I *am* using the throbber (the blue spinner)! (I haven't changed anything from the default setup.)

I can't tell when it's going to happen, but when it does it stick around for a while. Sometimes shutting down Firefox completely and restarting seems to get it to work again but I don't know if this is just coincidence.

I was having this problem as well. Per a warning on the Drupal Status Report, I increased memory_limit to 96mb. Still no go. I then increased to 128mb, now it is working fine.

The file I was trying to upload was small byte-wise, 1.4mb, but the resolution was big: 2592 x 1944. It was probably giving the imaging API a goodly task. Here are details on my setup/symptoms:

Drupal 6.10
FileField 6.x-3.0
ImageField 6.x-3.0

Trying to upload using the AJAX Upload button gave a JS error:

An HTTP error 0 occurred.
/filefield/ahah/image/field_image_type_image/0

Using the Save button redirected to a blank page with this url:

/filefield/ahah/image/field_image_type_image/0

That happened if I tried the AJAX button and then the Save button. If I tried the Save button without trying the AJAX button first, I was sent to this URL and a blank page:

/node/add/image

This was in Firefox and Safari on OSX 10.5. In all instances the files were uploaded to /sites/default/files/ and were appropriately named.

php.ini settings were:

upload_max_filesize = 4M
post_max_size = 8M
memory_limit = 32M

Again, I solved my problem by increasing memory_limit to 128M

Cheers,
Robert

P.S. Increasing the memory limit also fixed another problem I was having: when trying to edit a node with an imagefield, I was getting a blank page.

subscribe - getting same root error as first post.

subscribe

Drupal 6.11
FileField 6.x-3.0
ImageField 6.x-3.0

php.ini settings were:

upload_max_filesize = 20M
post_max_size = 20M
memory_limit = 128M

When i try to upload:
An HTTP error 0 occurred.

any ideas?

Hi everybody!

Using Mac OS X, just upgraded to Drupal 6.12 from 6.11. When uploading images, upload still fails with FF resulting javascript alert as all ready mentioned. With Safari, upload successful but only one time, editing post will lose the uploaded image.

Upload system has been set to 'public'. Filefield and ImaField both versions 6.x-3.0. And the error occurs no matter the image size and resolution; even with standard photosizes 600px etc. Memory limit is set to 64M.

solved!

I had a self made cck field module that made the problem!

thx

I'm also having this problem. On my development machine, I can set php_value memory_limit 96M, and then it works fine. However, when I try to add the memory_limit to .htaccess on my (shared) hosting deployment, I get internal server errors, so I'm guessing they disallow that setting. It seems I'm stuck with 32M, and that apparently is not enough. I'm wondering what filefield/imagefield does when uploading an image; it's only about 2.5M, so why does uploading such an image require so much memory?

Btw: ini_set("memory_limit", "96M") does in fact change the memory limit, but it doesn't solve this problem, as settings.php is not read (or not soon enough?), as described at http://drupal.org/node/422474. Is there a way around the issue using ini_set?

svdoord, the high memory requirement is usually caused by scaling down an image. If you're uploading a 2.5MB image, that's probably about... 4000x3000 pixels? According to references I've seen (not positive about the accuracy here) it takes 3 bytes per pixel processed in GD (4 bytes per pixel if there's an alpha channel). So 4000 x 3000 x 3 = 36000000 bytes, or 34.33 MB. So it requires 34 MB of memory just to read the 2.5 MB image into GD, then there's additional memory needed for actually scaling down the image.

The only options available are:
- Increase your PHP memory limit.
- Use ImageMagick instead of GD, this offloads the memory requirement from PHP and puts it on ImageMagick instead (note, this would require a small patch to ImageField to make it use ImageAPI's scaling function).
- Upload a smaller image. :-P

For most sites, increasing the PHP memory limit is the most acceptable option, as many servers do not even have ImageMagick available.

We've been experiencing similiar problems with this function for a while now.

OS: RedHat Enterprise 5, php 5.1, php-gd installed
Drupal: 6.10 (i know I know)
Browser 1: Safari
php memory: 512MB
max upload size: 100MB
image upload size: 4700bytes

Click on button to add image.
Image selected from user's drive
Click on upload button produces:

Save node, image appears both in view and in edit modes.

Problem: This is very disconcerting for users. It works ok for our staff, but won't work at all for our users.

We've increased the memory of our php stack, reduced the sizes of images we've uploaded...to no avail. We can't make the thumbnail appear in the edit screen without seeing the code dump or saving the node first.

FYI: We also use IMCE to upload images in other node types. IMCE is uploading/scaling the images just fine. Suspect the issue relates to either cck, filefield, or imagefield module's implmentation of some flavor of java because the behavior is different on different browsers.

I can't help but think it's filefield's ahah implementation...

Forgot to mention: using Firefox as a browser, it works fine, most of the time. But we get the same results with Opera that we do with Safari.

trailerparkopera, are you using FCKeditor? It breaks Drupal's AHAH implementation. See #248146: File upload throws error on attach only when FCKeditor is on page.

Agree with trailerparkopera. And no, not using FCKeditor. Also tested having ImageCache disabled. And I get the error even with really small images.

Memory limit is set to 96M, does not help.

I just encountered the same upload problem. I am using OSX 10.5, and the problem occurs in FF as well as Safari (both up-to-date).
The funny thing is that for some photos it works and for others it doesn't (if they are heaving same filesize).

The error I get is also:

HTTP-error 0
/filefield/ahah/content_type/field_foto/0

I too am getting the same prob.
Problem is not only with uploads but everything that has ajax functionality.
It occurs whenever i click "add another item" button for a cck field.Also occurs while making views.
I think someting is breaking ajax everywhere

I have just witness a case where disabling Devel's theme developer module - which wraps everything into lovely span tags - did the trick.

in my case working fine on my local system(windows xp) but http error 0 pops on linux server(provided by GoDaddy.com).
I removed all contributed modules, activated upload module(core- optional).
Created a new page content. while creating a page tried to attach a file and clicked on attach button.
progress bar appears and javascript error box pops up.click on save button and the file i tried to attach is seen attached.

Made a fresh Drupal 6.12 installation on linux.No contributed modules.activated upload module(core- optional) and followed the same procedure of creating a page. same result.

Made a fresh Drupal 5.18 installation on linux.No contributed modules.activated upload module(core- optional) and followed the same procedure of creating a page. while creating a page tried to attach a file and clicked on attach button.A large alert box pops up saying :

"{ "status": true, "data": "\x3ctable\x3e\n \x3cthead\x3e\x3ctr\x3e\x3cth\x3eDelete\x3c/th\x3e\x3cth\x3eList\x3c/th\x3e\x3cth\x3eDescription\x3c/th\x3e\x3cth\x3eSize\x3c/th\x3e \x3c/tr\x3e\x3c/thead\x3e\n\x3ctbody\x3e\n \x3ctr class=\"odd\"\x3e\x3ctd\x3e\x3cdiv class=\"form-item\" id=\"edit-files-1-remove-wrapper\"\x3e\n \x3cinput type=\"checkbox\" name=\"files[1][remove]\" id=\"edit-files-1-remove\" value=\"1\" class=\"form-checkbox\" /\x3e\n\x3c/div\x3e\n\x3c/td\x3e\x3ctd\x3e\x3cdiv class=\"form-item\" id=\"edit-files-1-list-wrapper\"\x3e\n \x3cinput type=\"checkbox\" name=\"files[1][list]\" id=\"edit-files-1-list\" value=\"1\" class=\"form-checkbox\" /\x3e\n\x3c/div\x3e\n\x3c/td\x3e\x3ctd\x3e\x3cdiv class=\"form-item\" id=\"edit-files-1-description-wrapper\"\x3e\n \x3cinput type=\"text\" maxlength=\"256\" name=\"files[1][description]\" id=\"edit-files-1-description\" size=\"60\" value=\"TN_15-10-08_M10b.jpg\" class=\"form-text\" /\x3e\n \x3cdiv class=\"description\"\x3e\x3csmall\x3ehttp://www.adroitusinnovation.com/wiki/files/TN_15-10-08_M10b.jpg\x3c/small\x3e\x3c/div\x3e\n\x3c/div\x3e\n\x3c/td\x3e\x3ctd\x3e8.98 KB\x3c/td\x3e \x3c/tr\x3e\n \x3ctr class=\"even\"\x3e\x3ctd\x3e\x3cdiv class=\"form-item\" id=\"edit-files-2-remove-wrapper\"\x3e\n \x3cinput type=\"checkbox\" name=\"files[2][remove]\" id=\"edit-files-2-remove\" value=\"1\" class=\"form-checkbox\" /\x3e"

I'm also having the same issue, but it works fine in Firefox 3.0.10, also works on my clients home PC (IE7, not sure of exact version).
It only seems to be failing on Safari, both my version 4 beta and my clients version of safari (once again not sure, but probably not the beta).

I had FCKEditor installed, but turning it off gives the same result (ahah response rendered directly to the page).

I'm using Dreamhost, so don't have control over php ini settings.

I found a way to consistently reproduce at least part of this error.

If you start uploading a file and then click the form submit button before the file upload complete you'll get redirected to the ahah progress callback URL (http://vs.localhost/filefield/ahah/vs_observation/field_observation_samp...) with output similar to the following:

The issue here is not PHP or PHP.ini settings. I have thoroughly gone through the php.ini file for both our development and live server and they are identical. Upload and post max size are 16M which is more than enough for the images we are trying to upload. It works on our development server, but not on our live server.

Firebug reports no JS, DOM, or Network errors.

I have tried the uploader in Firefox 3.x and IE7/8. I get the following results. They are inconsistent, and difficult to duplicate.

1. The page sits for about 30 seconds, then says 'HTTP 0 Error' with an alert
2. The image upload form simply disappears after clicking Upload
3. The upload stalls out, you hit refresh, and the Upload button is greyed out.

It seems like one out of every 15 tries, it will actually upload the image and I get the imagemagic conversion output.

In case 1 and 2, the data field is "".

If you disable Javascript, the image upload field works. So, something leads me to believe that this is Javascript related, not a php.ini configuration.

Like I said its very difficult to duplicate the error because I get a different result each time I try to upload an image, and every so often it will upload the image.

Does anyone have any idea how to fix this? We running this on a large website on a private server, CentOS 5 with all the latest server stuff, Drupal 6.10.

Disabling RDF module removes the problem for me.

I haven't discovered a platform or browser which this problem will not reproduce itself on.

All contrib modules are up to date.

Please let me know if I can provide any more info.

Thanks Shawn_Smiley, that's definitely a situation that will cause the problem. I'm not sure if disabling the node form Submit button during upload would be a good idea, but it's something I can think about.

gh0st25: How can you say that upload works perfectly fine on one server but not another, then say it's a JavaScript problem? Unless there's a way to reproduce the problem on any server then it's probably not something that can be fixed through changes to the code. I can intentionally misconfigure my own servers with PHP limits that are too low to reproduce some of these problems, but these inconsistent problems are really difficult for me to fix without knowing what steps I need to take to reproduce.

The servers are exactly the same, I can't reproduce the error every time either. The only difference is one has a memory limit of 256 and the other 192, perfectly fine for uploading an image.

I have a chance of error like one out of every 5 uploads, I'll have to close Firefox and start over.

I'm having the same problem here... Any progress on this?

I just ran into this locally with my default OSX install of PHP.. I enabled the imageapi_imagemagick module, made sure the convert path was correct, but all of the imageapi calls kept trying to still use the GD libraries instead of imagemagick (the "image_toolkit" variable was set to "gd"). At this point, when I'd upload an image I'd get an error back just saying "An image thumbnail was not able to be created" from line 95 of imagefield_file.inc.

So I manually set the "image_toolkit" variable to "imagemagick". Then when I uploaded an image inline I started getting the error in this issue ("An HTTP error 0 occurred").

Quick followup.. when I submit the form itself it gives this error:

FYI regular attachments work fine, it's just image attachments that are failing.

FYI for the tests I was using the main Zen theme.

ImageField is simply calling the core image_scale() function, which is independent of ImageAPI (which basically re-invented all the image handling entirely). If you have the core image toolkit set to GD then GD will attempt to be used, same as resizing of user pictures by user.module.

So shouldn't ImageField use ImageAPI so it could make the imagemagick library available instead of limiting it to only GD?

Same problem here.
I have one content-type with two imagefields (one single-value and one multiple value).
1st imagefield works ok, 2nd doesn't (http error 0).

Everything works again if i disable php extension php_uploadprogress.

Tested with Firefox 3 and Chrome 2.

Hi, I have the same error with version 6.x-3.1.

My experience http://drupal.org/node/493554#comment-1865970 is that this is happening every time in Firefox 3.5.1 on one computer but not at all on another with the same browser. IE and Safari are OK on same computer. Running Vista. Uploading images of 1k without resizing or thumbnail creation. The upload process just hangs and if you save the entire form you get the big ahah wrapper error. It happens in IMCE or Filefield. The 1k file is uploaded but the Status field in the Files table is not set to 1 and the process doesn't finish. I have tried clearing all cache. It also hangs when uploading non image files with IMCE. Upload progress circle keeps going on a word doc file after disabling filefield, imagefield, imageapi, imagecache, etc modules. Messages in progress bar "Connecting to testsite.com", "Waiting for testsite.com", "Transferring to testsite.com".

Sounds like it is a problem in Drupal core or in Java. Could this be caused by hitting Esc during an upload and leaving some switch on? It seems like the next upload should clear this.

For me the problem was simply devel module.
when you select an option like show memory usage or query logs ... devel breaks ajax action.
turn off these options and imagefield is ok

With:
Apache/2.2.10 (Win32), PHP/5.2.6
IE8 and google chrome navigators (same result)
Drupal 6.x, ImageField 3.1

I have 2 cck's fields one for image other for file, and get the following:

- with php's uploadprogress.dll off

file attachment (drupal core upload): attach --> OK
image: upload --> http error 0 showed on browser (* showed on apache log)
image: save (without previous upload) --> http error 0 showed on browser (* showed on apache log)
file: upload and then save --> OK
file: save (without previous upload) --> OK

- with php's uploadprogress.dll on file upload fails too:

file attachment (drupal core upload): attach --> OK
image: upload --> http error 0 showed on browser (* showed on apache log)
image: save (without previous upload) --> error (** showed on browser)
file: upload --> http error 0 showed on browser (* showed on apache log)
file: save (without previous upload) --> OK

(*) = Parent: child process exited with status 3221225477 -- Restarting.
(**) = Error 324 (net::ERR_EMPTY_RESPONSE): Error desconocido.

OK. My page loads had also become extremely slow so I disabled all my Firefox addons. Now images upload. Not sure if it was Firebug or something else, but my image uploaded now. I don't know yet if it will work every time.

After #61, I reinstalled everything again in other windows machine, with Apache 2.2.11 and PHP 5.2.10, adding the modules carefully one by one, and everything works fine now.

Throwing another anecdote on the pile. Quirky cause and quirky solution, so likely not applicable to most people, but maybe it might serve as a piece of evidence in tracking down the mechanism for the error.

I can't adjust the php memory limit on my host directly (very weird, long story), but I can do it with the Drupal Tweaks module. I had used Drupal Tweaks to adjust it up to 96M, then I disabled Drupal Tweaks (since I didn't think I needed it anymore).

I started uploading images, and all went well until I tried to upload a large (pixel-size, not file size) image. Then I got this same error that everyone else is getting:

An HTTP error 0 occurred.
/filefield/ahah/story/field_image/0

This confused the hell out of me because I had absolutely no such problem in my local dev environment (duplicate Drupal setup, duplicate images).

Reading through this thread, I figured I'd try the suggestion to up my php memory limit to 128M, so I re-enabled Drupal Tweaks, made the change, and disabled Drupal Tweaks again. Just on a hunch, I took a look at the Status Report, and lo and behold... the php memory limit had dropped down to its default 32M! OMGWTFBBQ!

Turns out Drupal Tweaks needs to stay enabled for your tweaks to stick around, so while I was happily uploading images, thinking I was working with 96M, I was really only working with 32M. When I upped the memory limit and then actually verified that the upped memory limit was still in effect (duh!), the problem disappeared.

Now I have the memory limit set at a nice, bloated 128M and everything is going swimmingly.

The End.

Same error, dont know coding so cant say much else.

Have the newest modules as of today and it still does it.

Hi,

I had this bug with my browser Seamonkey 1.1, updating it to version Seamonkey 2.0beta1 solved the bug for me!

Not a solution really..

Another note to an already bloated pile.

After finding this problem, went to another site it used to work and... WTF? Now uploads don't work.

All my settings are well above the needed levels... I'm using a W7 machine to handle sites on shared hosting.

So I go and try with IE8 and... WTF? Now uploads do work. So where does this lead us? I could upload images before Firefox 3.5.x. Not anymore...

I leave this to the cognoscenti... I'm just so frustrated because something I thought was now a known procedure just didn't work.

Cheers.

I too am getting the same error. I get it in Firefox 3.0.12-1 on Fedora 10. I have not got it, yet, in Konqueror or Sea Monkey.

I get it with a custom node type
An HTTP error 0 occurred.
/drupal/filefield/ahah/picture/field_picture/0

With Ubercart
An HTTP error 0 occurred.
/drupal/filefield/ahah/product/field_image_cache/0

But not with an Image node from the Image module. This works fine.

I get this error regardless of whether I use ImageAPI GD2 or ImageAPI ImageMagick

Drupal 6.12
Database updates Up to date
File system Writable (public download method)
GD library bundled (2.0.34 compatible)
Image gallery Galleries defined
Image import Import directory sites/default/files/import exists.
Image module directories Exists (sites/default/files/images).
Image toolkit The gd toolkit is installed.
ImageAPI GD Memory Limit 64M
MySQL database 5.0.27
PHP 5.2.6
PHP memory limit 64M
Web server Apache/2.2.3 (Fedora)

Also present in Firefox 3.0.13

Is this an underlying issue with Drupal AHAH?

http://drupal.org/node/344693

Title is now confusing, and I don't use any of those plugins.

I'm having the same problem here...

I was also getting this same issue and fixed it by disabling a FireFox plugin that was causing the issue "smarterFox". This fixed it.

I've seen this happen in IE and Chrome though. So its not just Firefox plugin system.

I get the error in Opera 10, but not in Firefox right now.

subscribe.

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

PECL not installed

FCKeditor 6.x-2.0-beta3 + FCKeditor 2.6.5

Could it be that these browsers don't like the \x3c and \x3e stuff from drupal_to_js? For instance, PHP's json_decode() does not like it either.

#81 is on to something.

I found that when using ImageMagik as the toolkit, this issue persisted as long as I did not have any presets in ImageCache. As soon as I added some, it went away, and an error about failing to create the thumbnail reared its head.

Now it seems I have GD2 vs. ImageMagik issue, but I have gotten around the:
An HTTP error 0 occurred
/filefield/ahah/ei_header_photos/field_ei_header_photos/0

Problems.

Hope this helps,
Andrew

this is driving me crazy too. when I press "upload" I get the HTTP error 0, but if i just save then everything works fine.

have tried replacing jquery.form.js, playing with permissions, changing php memory, nothing get's rid of the error message :(

i actually got the error of cannot divide by zero on line 517 i believe in image module, which is drupals core mod. The latest 6x. drupal uses $..path... instead of $.. destination, and if i comment out the resizing in the module the image successfuly uploads without errors. If i put it back, the image still gets uploaded to the files / pics directory, but gives HTTP 0 and is not getting listed. All of my other image related modules such as foto album, upload images of 5mb+ - no problem, so it's not max post nor max upload... nor mem. Something to do directly with coding in the module.

I believe #81 needs to be followed, as I'm having the same issue, only in my oper browser and if js is enabled. So obviously it can't be a server issue. Tracking this down a little furter.

-> did some testing:
- removed the backslash of \x3c and \x3e -> in my chrome browser (where the upload works), this uploads the image, but the server answer coming back is just:

x3cdiv id="edit-field-profile-foto-0-ahah-wrapper"x3ex3cdiv class="form-item" id="edit-field-profile-foto-0-wrapper"x3e x3clabel for="edit-field-profile-foto-0"x3eFoto: x3c/labelx3e x3cdiv class="filefield-element clear-block"x3ex3cdiv class="widget-preview"x3ex3cdiv class="imagefield-preview"x3ex3cimg src="http://dev.evangelisch.de/sites/default/files/imagefield_thumbs/user_picture/skydive_13.jpg" title="skydive.jpg" /x3ex3c/divx3ex3c/divx3ex3cdiv class="widget-edit"x3ex3cinput type="hidden" name="field_profile_foto[0][fid]" id="edit-field-profile-foto-0-fid" value="3190" /x3e x3cinput type="hidden" name="field_profile_foto[0][list]" id="edit-field-profile-foto-0-list" value="1" /x3e x3cinput type="submit" name="field_profile_foto_0_filefield_remove" id="edit-field-profile-foto-0-filefield-remove" value="Entfernen" class="form-submit" /x3e x3c/divx3ex3c/divx3e x3c/divx3e x3c/divx3ex3cscript type="text/javascript"x3ejQuery.extend(Drupal.settings.ahah, { "edit-field-profile-foto-0-filefield-upload": { "url": "/filefield/ahah/profile/field_profile_foto/0", "event": "mousedown", "keypress": true, "wrapper": "edit-field-profile-foto-0-ahah-wrapper", "selector": "#edit-field-profile-foto-0-filefield-upload", "effect": "fade", "method": "replace", "progress": { "type": "throbber" }, "button": { "op": "Upload" } }, "edit-field-profile-foto-0-filefield-remove": { "url": "/filefield/ahah/profile/field_profile_foto/0", "event": "mousedown", "keypress": true, "wrapper": "edit-field-profile-foto-0-ahah-wrapper", "selector": "#edit-field-profile-foto-0-filefield-remove", "effect": "fade", "method": "replace", "progress": { "type": "throbber" }, "button": { "field_profile_foto_0_filefield_remove": "Entfernen" } } });x3c/scriptx3e

-> This is actually oky. I except opera to behave the same. Well, doing the same thing in opera doesn't work.
Additionally: I can remove the image in opera successfully, this also contains the \x3c thingy, so this wouldn't work either.

I guess we can exclude #81 from possible reasons.

@viktor.denischik: can you give some more detailed information on this? I couldn't find the line 517

One additional comment: Image is being uploaded into the folder.

"removed the backslash"
I thought about replacing the \x3c with "<", and \x3e with ">" (or the other way round, I don't remember). Not just remove the backslash!!

But anyway, this was only a guess.

@donquixote: tried this aswell -> doesn't work either.

Try to check .htaccess file in the folder uploaded.

can't be the .htaccess file, since the problem only occures with opera

.htaccess looks like this:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

This is happening to me too... A couple points of interest.

1) only happens in firefox (im using 3.5.3)

2) has nothing to do with file size (in my case)

3) If i ignore the upload button and just preview the post the image is displayed correctly!

1) only happens in firefox (im using 3.5.3)

Commonly this is caused by Firefox extensions, most notably ad-blocking software.

though are there any extensions that might cause that for opera? I tried it with a clean opera portable version. Strangely it works with firefox without any problems.

Why would it be a plugin/extension browser issue? This is rooted in the AHAH handling. I can replicate the issue in any browser.

One of two things usually happens:

1. HTTP Error 0 occurred in (function)/js

or

2. The upload form uploads the file, then disappears. Or, you click Add File, and the form disappears.

I saw the same thing happen with my own form that uses AHAH. One of the variables passed through had a typo, and it was causing my form to disappear.

Hmm ok I do have a slew of extensions running so that may be part of it. Here's the exact error I'm getting in case that's beneficial:

An HTTP error 0 occured
Filefield/ahah/council_member/field_council_image/0

My file path is sites\default\files\imagefield_thumbs

ImageField 6.x-3.2 and Opera 10 - this error appears. Can't wait for fix

I have the same problem here with FF 3.5, Opera 10 and IE8. Error is:

Directory premissions:

Already disabled FCKeditor.

Module versions:

Updated jQuery to 6.x-2.x-dev an nothing changed. Also tried GD2 instead of ImageMagic: no difference. Even disabling AdBlock Plus in FF doesn't change anything.

So for comment #100, if you used multiple browsers, that would further prove (IMO) that it has nothing to do with a browser plugin. I got the same error on Chrome, and Chrome has no plugins (at least mine does not).

check your admin/reports/status
it recommends 96M of memory
I made it 128M using http://drupal.org/node/207036

and problem was solved

EDIT I am allowing a maximum of 2MB upload (through filefield configuration)

I'm having a hard time understanding, how this should solve the issue if it only affects some browsers.

I tried 128MB and 256MB, but still have the problem.

I can't affirm, that this problem is specific to any browser.

Marking this as critical bug, as I have seen, this problem still exists in D7 core.

Earl Grey, that's fine moving to a bug, but I still insist, 90% of the time this is server configuration issue. It's just that ImageField/FileField and Drupal core in general isn't good at telling you what the error is.

The only legitimate report so far is #612754: JS upload broken in Opera 10. Every other report I've received in the past 4 months has been configuration related.

I really want to believe, that this is a configuration error. I'd love to correct my configuration to get image field working.

I just uninstalled any module, I don't need. I created a new content type with a file field and the upload works finde. I switched the type of the field to 'image' and the error is there again. In both cases, I uploaded the same file (189k jpg).

Interesting about the error is, that in both situations, the file is uploaded correctly (I can see it via FTP). So, the question is, what does ImageField different to FileField, after the image is uploaded.

I thought, it depends on the file extension restriction (I recently uninstalled mime detection module), but when I set the restriction to 'jpg' in the FileField, there is still no error. All I can tell so far ist, that it has nothing to do with the validators, provided by ImageField, as I disabled them by returning an empty array in imagefield_widget_upload_validators.

So, the question is, what does ImageField different to FileField, after the image is uploaded.

ImageField creates a thumbnail. If you run out of memory when the thumb is created, then it gives you the error. It sounds like you've increased your memory limit through the configuration, but are you sure it's having any effect? Most shared hosts will cap you at 16 or 32MB. You should visit admin/reports/status/php and see what the "Local setting" is for the memory_limit.

This tapping in the dark is quite depressing :(

For the sake of documentation:

Drupal 6.14
misc/ahah.js (line 90 et al)

Arguments for function complete(response, status):

Request time:
In Firefox I have to wait a little until I get the response.
In Opera I get an immediate response - which tells me there has not been any serious communication with the server.

Downloading the latest jquery.form.js did the trick for me.
http://jquery.malsup.com/form/#download

(the initial reason for trying this was that I wanted to have an uncompressed version)

The file lives in the /misc folder, but maybe there are ways to have it in custom module or theme and disable the file in misc/ ?
I also want to warn that we have to check compatibility with the aged jQuery version shipped with Drupal core.

EDIT:
I see that others tried this before, and it didn't help them. So there must be something else. Damn.

I am always too fast in posting..

I used to have this bug on imagefield, filefield and upload module. And the above tests were done with filefield, in order to isolate from imagefield things. I now did another test with imagefield, and it's fixed as well (for now).

I think it's a problem with core ahah.js and jquery.form.js. Could even be jquery itself.
None of the above mentioned modules do always fail, but they fail often enough to show there is something wrong.

From the troubleshooting above I would guess that in some cases jQuery does wrongly assume that the response is already there, when in fact it is not. Or it assumes that the response will never arrive? Or that it was interrupted?

For the real troubleshooting I think I need to get the correct versions of the uncompressed jquery and jquery.form.js. Another time..

digging further.

jquery.form.js
function fileUpload()

The misfired onload event happens when the iframe is loaded with empty content.
In Opera this only happens after the 'i.appendTo("body")'.

The following solves the problem for me (all in fileUpload() in jquery.form.js):

I attached equivalents of the old and new version below.
I didn't have the uncompressed version available, so I uncompressed the ajaxSubmit() function with Firebug, and changed only this part. The difference between the files is nothing but the two lines flipped, as shown above.

@quicksketch: I can increase my memory limit as I want. I tried 512MB, and the value in admin/reports/status/php changes accordingly.

@donquixote: It seems, that we have different problems. The .js-file that fixes the problem for you, doesn't change anything for me.

But: I figured out, that this problem depends on the file size. I shrinked the file to 13kb and the upload works now! So I guess, that the value for the ahah timeout is to low or any other timeout when creating the thumbnail. Actually, if 512MB aren't enough for creating the thumbnail, this seems not to be a memory problem.

@Earl Grey
Maybe you can do the same and do some debugging with uncompressed js files? Or use Firebug to inspect the response?
Do you need to wait before the error pops up, or does it happen immediately after clicking the button?

Can you give me a hint, where wo start with debugging? I have FireBug installed, but break points in jquery.form.js do not have any effect.

I checked one Request with the following result:

The request is sent and needs 2.17s. It transfers 188kb of data, what not completely, but nearly matches the size of the uploaded image (193kb). I attached the request to this post (removed the binary data of the image).

The answer only consists of a header, the answer itself is emtpy. I also attached the headers to this post.

After that test, I created some test images, as I wanted to see, what is the maximum size of the image, that can be uploaded without errors.

First thing, I found out is, that the problemd doesn't depend on the file size, but on the size the _uncompressed_ file has. I can upload a 304k/5.32M (compressed/uncompressed) file, that works perfectly. On the other hand, 189k/21.29M doesn't work.

More numbers:

• 584.24k/12.17M works
• 699.14k/15.03M doesn't
• 590.93k/12.45M works
• 602.21k/12.72M works
• 610.40k/13.01M works
• 620.61k/13.28M works
• 630.29k/13.57M works
• 647.91k/14.14M works
• 665.62k/14.73M works
• 665.21/14.78M doesn't

I can see a memory_limit of 64M, post_max_size at 8M and upload_max_filesize of 2M. Nothing near the 15M limit.

To your last question: I have to wait for the error to come up. The time to wait depends on the uploaded files size.

I have FireBug installed, but break points in jquery.form.js do not have any effect.

With which version of jquery.form.js do you work? Is it uncompressed?
Another thing to try with breakpoints (or stupid alerts or console.log) is ahah.js (also found in misc).

The answer only consists of a header, the answer itself is emtpy. I also attached the headers to this post.

But you get a non-empty response for successful requests?

It seems this is a server-side issue in your case.

I can see a memory_limit of 64M, post_max_size at 8M and upload_max_filesize of 2M. Nothing near the 15M limit.

Did you confirm that with phpinfo() ? And you played with the values, and they didn't make a difference?
We are back on guesswork level!

With which version of jquery.form.js do you work? Is it uncompressed?
Another thing to try with breakpoints (or stupid alerts or console.log) is ahah.js (also found in misc).

I used your jquery.form_.js_.broken.txt for debugging, as it seems to be the original version, only without compression. I set breakpoints in the ahah.js, but none of them stopped the script. Maybe I'm using firebug in a wrong way.

But you get a non-empty response for successful requests?

The response for sucessful uploads is not empty.

Did you confirm that with phpinfo() ? And you played with the values, and they didn't make a difference?

The values are from admin/reports/status/php. AFAIK, this is part of an phpinfo(). Changing them affects the phpinfo(), but doesn't have any effect on the error (I increased memory_limit to 512M, post_max_size to 32M and upload_max_filesize to 32M).

We are back on guesswork level!

I don't think so. We already know, that the error (in my case) depends on the size the image has when it's uncompressed. The error is somewhere between the upload and the thumbnail creation, as all files are uploaded, even those that lead into the ahah error. There is no thumbnail created for images with an error, but it is created for the others.

So the question is: Which module is responsible for creating the thumbnail? And what other modules does this module use? (maybe something like FileField -> Image toolkit).

Do you have a time limit in your PHP ? Or maybe there's a time limit in the javascript?
Or any limit in the filesystem?

Do you have a time limit in your PHP ?

Yes, it's 30s for the max execution time, but it's only 2-5sec until the error occurs after I click the 'upload'-button. There is also a default_socket_timeout, but this is set to 60s.

Or maybe there's a time limit in the javascript?

Is this a browser specific setting? I already tried FF, IE and Opera. I don't think, they all have the same timeout. Are there any timeout settings in the script itself?

News: I tried the same on Opera while JavaScript was not activated. It gives the same result as my last test: if the uncompressed image is too large, uploading results in an empty page. With smaller images, the image is uploadet correctly and after the upload, the content creation form is displayed again.

Or any limit in the filesystem?

Nope. I just converted the image to bmp and uploaded it via FTP (21M) with no problems.

I think you need to do some PHP debugging now. xdebug is supposed to help with that afaik, but so far I only used it for profiling. At least it can tell you which functions have been called or not, but I didn't manage to make it tell me about sequence of function calls, so far.

You can do it with echoes and devel dpr/dvr.. good start would be any place where you suspect that thumbnails are created.

Can you play with other modules that offer image uploading? Such as, images in user profiles?

Okay, here we go:

I tried uploading the image in my user profile and *bang*, got a out of memory error. After combing through the FAQ of my hoster (1und1, Germany), I decided to call them. After some time, the guy un the line figured out, that they have a hard limit of 32MB. Everything I put into php.ini that goes beyond this limit is ignored! No hint in phpinfo() and nowhere else.

Nevertheless, it would be great if ther is a way to tell the user what problem he runs into, instead of displaying a blank page. Is there any way to force the webserver to display the error?

After some time, the guy on the line figured out, that they have a hard limit of 32MB.

*Sigh*. Well server configuration strikes yet again.

Nevertheless, it would be great if ther is a way to tell the user what problem he runs into, instead of displaying a blank page. Is there any way to force the webserver to display the error?

Unfortunately if the server runs out of memory, it typically will return an entirely blank page. This doesn't give any indication of what the problem was. It could be a parse error, could be memory, it could be anything that makes PHP crash. There is no opportunity for Drupal to return more useful information to the calling page telling the user what happened.

You can enable the "error_reporting" option in php.ini (if your host allows it), which will return a big HTML table describing the error. While this is helpful for non-ajax requests, it's not something that is predictable enough for Drupal to parse during AJAX calls.

I thought that phpinfo() would show the true memory limit.. what a pity. Shared hosting sucks - so far I didn't find any with a decent memory limit. And none of them publishes any info about memory_limit.

There is one solution that I imagine. The idea is to remember somewhere (in the database, for instance), when a request is started, and remove that note when the request is successful. In a later request, all interrupted requests can then generate a Drupal message, that is queued for the next regular page request.

Maybe you also find that info in your PHP or Apache error log files - if you have access to any of them.

--------

About setting that issue to "support request":
We are not sure if everyone here has the same issue. Maybe some suffer from the jquery.form.js bug, others suffer from memory_limit, and others .. who knows? Let's see if the complaining continues.

And for the jquery.form.js bug, maybe we need to file a core bug report?

core bug already exists #240777: Attach: An http 0 occurred
There's main trouble with update jquery.form.js because 6-x branch is frozen already

So what's about memory_limit suppose imagefield should drop a line into readme.txt about big images and shared hostings, I prefer using imagemagick toolkit which use really less memory then GD

So what's about memory_limit suppose imagefield should drop a line into readme.txt about big images and shared hostings, I prefer using imagemagick toolkit which use really less memory then GD.

I think it should be possible to use ImageAPI and let the user choose the image toolkit, he prefers.

After reading this thread I've managed to fix the problem in my situation.

At first, I updated my version of jquery form js. That didn't seem to work.
Next, I've disabled all the add-ons in firefox and the problem has disappeared.

I think however, that large file size issues are completely separate from this issue. Simply because I was having this problem on ALL filesizes, even tried a tiny spacer gif.

I think it should be possible to use ImageAPI and let the user choose the image toolkit, he prefers.

If ImageAPI is installed, ImageField will use it automatically instead of the core image handling. So if you use ImageMagick, you won't be running into this specific memory problem.

Actually, I do have the same error, even when ImageAPI is installed, activated and set to ImageMagick. I have activated the debug information for ImageMagick, but it doesn't show up when I try to upload an image via ImageField.

I guess, the thumbnail of the image is created in imagefield_file.inc around line 85. There, you are using image_scale what is part of drupals image toolkit. I think, you should use imageapi_image_scale instead, if you want to use ImageAPI for creating the thumbnail.

BTW: if you remove the @ when calling image_scale, it is much easier to find the reason for the 'http error 0', as the memory limit error is included in the answer to the ahah-request.

@Earl Grey if you have a trouble with image_scale then check that you upload file with dimensions larger then pointed in scale, I remember if uploaded image is smaller then scale dimensions so no image created at all.

There is no problem with the image dimensions. I guess 2440x3050 should be enough for testing.

I just realized, that the D7 version get's the out-of-memory-error back as answer to the HTTP request. Would it be possible to display that answer to the user?

I'm getting the following message with ImageField 6.x-3.2:

an http error ) occurred.
/ubercart/filefield/ahah/product/field_image_cache/0

Does anyone has a fix for it?

Yes:

1) Read, what other people did to fix it
2) if nothing fits for you, post more details about the image, you are uploading, you directory-permissions, your webhoster, the memory_limit in your php.ini and everything else, that might be necessary to help you. Include the numbers of the post in this thread that describe, what you did while trying to fix your problem.

my issue is slightly different.

On Safari 4 the upload stalls with the tumbler just spinning forever on my local install.
On Firefox 3.5.4 works perfect. No problems.

I am only uploading small 100K images.

image attach gives me the 'HTTP error 0 occurred' for both browsers.

the new jquery.form.js did not help.
upped memory did not help.

D 6.14, all current modules.

Form still disappears 90% of the time trying to upload an image, even with 256mb php memory on a dedicated server.

Are you sure, that there is no hard-limit configured? Did you analyze the request/response cycle via firebug? What is the result?

We're sure.

Why does this module require such high PHP memory limit to work?

Why does this module require such high PHP memory limit to work?

See comment #34.

Ours is at 256mb though, seems like a lot.

In #34 you say, that a patch is necessary to make image field work with ImageAPI. In #129, you told me, that it should work automatically.

What has changed between these two posts?

Earl Grey, sorry ImageField does not yet support ImageAPI. I was getting my modules confused. I added ImageAPI support to Image Resize Filter in #512046: Add support for ImageAPI if available, but ImageField does not yet have this ability.

Earl Grey added #618024: Add support for ImageAPI for the ImageAPI support.

Thanks damien. I just added a patch there.

@stripped your speech: please try ImageAPI with ImageMagick and please report the results of your investigation regarding the HTTP request/response cycle when uploading an image. You can try deactivating JavaScript to see, if there is any PHP error when uploading the file.

Would it be possible to detect the out-of-memory error in the ajax response, and show that in the alert, instead of a generic error message? This would at least encourage more specific bug reports, and we could have separate issues for unrelated bugs.

Seeing that we will not 100% get rid of this error, there should at least be a decent error message.

With my patch in #618024: Add support for ImageAPI, it should be easier to figure out the problem more detailed, as I removed the '@', supressing php warnings when scaling the image. If analysing the ajax traffic, you should see, what error comes back as answer to your ajax request. FireBug can do this for you.

I have no idea how to put this error into the message window. I guess, that's an ajax topic.

edit: nm

I'm getting the same error ("HTTP error 0 occurred") after updating to PHP 5.2.9 and with uploadprogress-1.0.1. At one point, Firefox would crash randomly whenever I tried to upload a file. Now, Firefox does not crash and the files get uploaded (< 5M at least).

#132 Earl Grey "There is no problem with the image dimensions."

I'll have to disagree with you on that. I have successfully passed this error. I came across this searching for the reason for my error. I was going through following, and when someone said try updating memory limit, I did get from 96m to 128m now. However, I still had the same problem.

I looked at the problem and tried by comparing pictures that worked to those that weren't. I have pictures from the manufacturer that are 3000x2000. Those pictures failed. I dropped 66.7% so the 3000 = 2000. The upload works. I'd have to say that the root of the problem for possibly most situations is dimensions. As most cameras are capable of producing large images, that might be one thing to look at first. It solved my problem, with Photoshop I'll just use the save for web and devices option to reduce, bicubic sharper. Hope this helps someone.

Matt

same problem. No changes fixed it.

But saving the page - not pressing upload- worked. I then had to go back to edit the page so I can enter the tags.

Even if you upload a small stamp sized image, the form disappears.

one more thing. Make sure the upload module is turned on. It says it allows users to upload content. But you are also a user. Solves the problem of uploads, but now the pictures don't seem to come up on IE.

Make sure the upload module is turned on. It says it allows users to upload content.

Turning on Upload module should not have any effect, it's a completely different solution than FileField/ImageField and I'd suggest that you not use it when using ImageField, since there's no point in having two different solutions for the same thing on one site. FileField replaced Upload module entirely in Drupal 7.

I agree with you the1who, I think it has something to do with the image dimensions. After making sure my client had changed the dimensions it worked. They had an jpeg that was saying the file was 1mb, but when the file was opened in photoshop the image resolution was set to 300dpi, so once it was set to 72dpi the file got smaller and the upload worked.

grandchamp_g: That's somewhat circumstantial - every time you re-save a JPG it looses quality. The only way to verify for sure is to take a high-rest TIFF or PNG and save it out in different JPG formats to see what trips it.

I have the same problem... to an extent...

All image uploading through filefield works fine for me on Firefox 3.5.5 in Win XP3.
However, my client is getting this error every time when they try to upload an image using IE 7.x in Vista
Could it not necessarily be a server configuration but a browser/OS configuration? I tested on my machine using IE 7.x with 2.5Mb compressed image and I had no error.

Also, my memory limits are as follows: memory_limit: 128M, upload_max_filesize: 10M, post_max_size: 20M
We are on a shared host with Liquid Web. I know we have access to change ini settings because I had a memory limit problem, changed settings in htaccess and was fine afterward.

I have a few questions for people commenting next:
What is your browser AND OS setup?
In what order did you install the modules you are using? I know this sounds inane but installation order has fixed other issues for me in the past. (No one has addressed this yet in this thread)
Is your field disappearing as well or are you simply getting the pop-up?

The end.

@wickedskaman:
A troubleshooting list is a good idea!

What we learned about this issue so far is that it's actually two issues - or more. One is a piece of javascript that causes problems in some browsers (this happens on client side), the other is a server-side issue that might be caused by memory limit or something else (we don't know).

A first step in troubleshooting is to find out which of the two issues you have (or if you have both). And here is how:
a) With the client-side / javascript issue, you get the error message immediately after clicking "upload".
b) With the server-side issue, you have to wait for the error message to pop up.
c) If you have both issues, my personal estimate is that you would get the symptoms of a).

Please correct me if I'm wrong.

Other things that will be useful to know:
- does this only happen with ImageField, or also with FileField, the upload module, or other modules that allow to upload files?
- Will the image upload be successful if you submit the entire form, without clicking the "upload" button?
- what exactly happens: are you redirected to a different page? does the button disappear?
- does it happen in all browsers?
- does it happen on a localhost drupal install with very high memory limit?
- does it help to replace jquery.form.js with the new version?
- very interesting: does the upload form on this issue queue work for you?

All of this will be interesting and useful information, but it will be a lot more useful if we know which of the two bugs we are dealing with!

@donquixote: I think that's a very good summation of the issue at hand. I think the a, b, c breakdown represents the problem in a very understandable way. I'm going to address the good questions you brought up with my particular issue.

My criteria meets choice A: error on upload click

Configuration

• Drupal 6.x with Ubercart 2.x installed
• Image field, filefield, and imagefield crop installed
• CCK, Views, Vertical tabs installed
• Remote shared Linux, PHP5.x, mySQL 5.x, memorylimit=128,maxupload=10,maxpost=20

Problem cropped up with:

• only happened after imagefield crop was installed and configured for a node
• only triggers on Vista machine for both IE 7.0.x and Firefox 3.5.5
• does not trigger on Win XP3 machine in Firefox 3.5.5 OR IE 7.0.x

What I have tried:

• changing memory limit settings

What I have yet to try:

• reinstalling the filefield, etc modules
• using the new jquery.form.js file
• "Will the image upload be successful if you submit the entire form, without clicking the "upload" button?"

I had this working since the start of the build of a site for a client. Suddenly this error started and I came to this forum page. Reading most of the posts led me to believe I too had encountered the same problem and I've been fighting this now for several hours.

Here were my steps that finally resolved the issue for me:

Both imagefield and filefield are version 3.2 installed on Drupal 6.14.

My php.ini memory_limit was 80MB, I increased it to 256MB.
Restarted apache.
Test failed again and form was still showing 80MB limit.

Shut off imagefield and filefield (and all dependencies) modules, then re-enabled the modules I turned off.
Ran update.php just to be sure everything was current.
Cleared the (stupid) Drupal cache via admin/settings/performance. (Yes, I know there are cache shut off modules, but none of them ever seem to completely shut off the caching - and for a developer, THAT SUCKS! - so I always have to use the "Clear Cache" button.)
Deleted the field and re-created it.
After all that, an upload test went through without error.

This was all done on one browser (Firefox 3.0.15) which was originally working, then broken for a while, then fixed after the above steps. Not sure specifically which step did it, but it's working again. I hope this will help others.

My tests were using a 30k jpg image at 466x160 at 72dpi.

Final php.ini settings:
memory_limit = 256MB
post_max_size = 128MB
upload_max_size = 128MB

Subscribing. . .

My situation:

Drupal 6.14
FileField 6.x-3.2
ImageField 6.x-3.2

upload_max_filesize = 100M
post_max_size = 100M
memory_limit = 528M

When I use the (cck) upload button in Firefox 3.5 (even with files as small as 10k), I get the massive error described in #35.

When I use the (cck) upload button in Opera 10.01 (even with files as small as 10k), I get a "An HTTP error 0 occurred.
/filefield/ahah/item/field_item_blahblah" error.

When I ignore the (cck) upload button and just go directly to save, the image is saved and everything works fine.

Nonetheless this behavior causes a lot of distress and confusion for my users, and is not good for site business.

I've tried most of the fixes described on this thread with no luck. I'm running out of optimism but going to try the remaining suggestions still.

Image field doesn't work for me in FF (in IE and safari does work).
I got this alert message also. after a I debugged a bit I found that The level that my process fails is at filefield.module:491 where's the :
" if (empty($field) || empty($_POST['form_build_id'])) { "
my $_POST is empty. Any ideas ?

@rwheindl, Miria, shua.adi (#159 ff):
Could you guys have a look at #157 and find out which type of the bug you are dealing with? As said, these are fundamentally different problems with similar symptoms, so it is really helpful to discuss them separately.

my $_POST is empty. Any ideas ?

Your entire $_POST variable gets dropped if you exceed the max_post_size variable for your PHP configuration. Basically, the file you're uploading is larger than you are currently allowed. There's about a dozen people in this same issue that had this problem, just read through it.

Mine was type A) with immediate prompt.