'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

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.

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:

{ "status": true, "data": "\x3cdiv class=\"ahah-new-content\"\x3e\x3cdiv class=\"form-item\" id=\"edit-field-topthumb-0-wrapper\"\x3e\n \x3clabel for=\"edit-field-topthumb-0\"\x3eTop thumbnail: \x3c/label\x3e\n \x3cdiv class=\"filefield-element clear-block\"\x3e\x3cdiv class=\"widget-preview\"\x3e\x3cdiv class=\"imagefield-preview\"\x3e\x3cimg src=\"http://my.whichbox.com/sites/all/files/imagefield_thumbs/images/author-uid/thumbnails/eggmuffin_0.jpg\" /\x3e\x3c/div\x3e\x3c/div\x3e\x3cdiv class=\"widget-edit\"\x3e\x3cinput type=\"hidden\" name=\"field_topthumb[0][fid]\" id=\"edit-field-topthumb-0-fid\" value=\"1187\" /\x3e\n\x3cdiv class=\"form-item\" id=\"edit-field-topthumb-0-data-description-wrapper\"\x3e\n \x3clabel for=\"edit-field-topthumb-0-data-description\"\x3eDescription: \x3c/label\x3e\n \x3cinput type=\"text\" maxlength=\"128\" name=\"field_topthumb[0][data][description]\" id=\"edit-field-topthumb-0-data-description\" size=\"60\" value=\"\" class=\"form-text\" /\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-field-topthumb-0-list-wrapper\"\x3e\n \x3clabel class=\"option\" for=\"edit-field-topthumb-0-list\"\x3e\x3cinput type=\"checkbox\" name=\"field_topthumb[0][list]\" id=\"edit-field-topthumb-0-list\" value=\"1\" checked=\"checked\" class=\"form-checkbox filefield-list\" /\x3e List\x3c/label\x3e\n\x3c/div\x3e\n\x3cinput type=\"submit\" name=\"field_topthumb_0_filefield_remove\" id=\"edit-field-topthumb-0-filefield-remove\" value=\"Remove\" class=\"form-submit\" /\x3e\n\x3c/div\x3e\x3c/div\x3e\n\x3c/div\x3e\n\x3c/div\x3e\x3cscript type=\"text/javascript\"\x3ejQuery.extend(Drupal.settings, { \"basePath\": \"/\", \"admin_menu\": { \"margin_top\": 1 }, \"fivestar\": { \"titleUser\": \"Your rating: \", \"titleAverage\": \"Average: \", \"feedbackSavingVote\": \"Saving your vote...\", \"feedbackVoteSaved\": \"Your vote has been saved.\", \"feedbackDeletingVote\": \"Deleting your vote...\", \"feedbackVoteDeleted\": \"Your vote has been deleted.\" }, \"tabs\": { \"slide\": false, \"fade\": false, \"speed\": \"fast\", \"auto_height\": false, \"next_text\": \"next\", \"previous_text\": \"previous\" }, \"popups\": { \"originalPath\": \"filefield/ahah/box_howto_part/field_topthumb/0\", \"defaultTargetSelector\": \"div.left-corner \\x3e div.clear-block:last\", \"template\": \"\\x3cdiv id=\\\"popups\\\"\\x3e\\n \\x3cdiv id=\\\"popups-title\\\"\\x3e\\n \\x3cdiv id=\\\"popups-close\\\"\\x3e\\x3ca href=\\\"#\\\"\\x3eClose\\x3c/a\\x3e\\x3c/div\\x3e\\n \\x3cdiv class=\\\"title\\\"\\x3e%title\\x3c/div\\x3e\\n \\x3cdiv class=\\\"clear-block\\\"\\x3e\\x3c/div\\x3e\\n \\x3c/div\\x3e\\n \\x3cdiv id=\\\"popups-body\\\"\\x3e%body\\x3c/div\\x3e\\n \\x3cdiv id=\\\"popups-buttons\\\"\\x3e%buttons\\x3c/div\\x3e\\n \\x3cdiv id=\\\"popups-footer\\\"\\x3e\\x3c/div\\x3e\\n\\x3c/div\\x3e\\n\", \"modulePath\": \"sites/all/modules/popups\", \"popupFinalMessage\": 0 }, \"ahah\": { \"edit-field-tools-field-tools-add-more\": { \"url\": \"/content/js_add_more/box-howto-part/field_tools\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"field-tools-items\", \"selector\": \"#edit-field-tools-field-tools-add-more\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"field_tools_add_more\": \"Add another item\" } }, \"edit-field-supplies-field-supplies-add-more\": { \"url\": \"/content/js_add_more/box-howto-part/field_supplies\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"field-supplies-items\", \"selector\": \"#edit-field-supplies-field-supplies-add-more\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"field_supplies_add_more\": \"Add another item\" } }, \"edit-field-topthumb-0-filefield-upload\": { \"url\": \"/filefield/ahah/box_howto_part/field_topthumb/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-topthumb-0-ahah-wrapper\", \"selector\": \"#edit-field-topthumb-0-filefield-upload\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"op\": \"Upload\" } }, \"edit-field-topthumb-0-filefield-remove\": { \"url\": \"/filefield/ahah/box_howto_part/field_topthumb/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-topthumb-0-ahah-wrapper\", \"selector\": \"#edit-field-topthumb-0-filefield-remove\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"field_topthumb_0_filefield_remove\": \"Remove\" } }, \"edit-field-howto-file-0-filefield-upload\": { \"url\": \"/filefield/ahah/box_howto_part/field_howto_file/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-howto-file-0-ahah-wrapper\", \"selector\": \"#edit-field-howto-file-0-filefield-upload\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"op\": \"Upload\" } }, \"edit-field-howto-file-0-filefield-remove\": { \"url\": \"/filefield/ahah/box_howto_part/field_howto_file/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-howto-file-0-ahah-wrapper\", \"selector\": \"#edit-field-howto-file-0-filefield-remove\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"field_howto_file_0_filefield_remove\": \"Remove\" } } } });\x3c/script\x3e" }

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:

{ "status": true, "data": "\x3cdiv class=\"messages warning\"\x3e\n \x3cul\x3e\n \x3cli\x3eThe theme registry has been rebuilt. \x3ca href=\"/admin/build/themes/settings/vitalsignstheme\"\x3eTurn off\x3c/a\x3e this feature on production websites.\x3c/li\x3e\n \x3cli\x3eThe theme registry has been rebuilt. \x3ca href=\"/admin/build/themes/settings/vitalsignstheme\"\x3eTurn off\x3c/a\x3e this feature on production websites.\x3c/li\x3e\n \x3c/ul\x3e\n\x3c/div\x3e\n\x3cdiv id=\"edit-field-observation-sampmeth-photo-0-ahah-wrapper\"\x3e\x3cdiv class=\"form-item\" id=\"edit-field-observation-sampmeth-photo-0-wrapper\"\x3e\n \x3clabel for=\"edit-field-observation-sampmeth-photo-0\"\x3eSampling method photo: \x3cspan class=\"form-required\" title=\"This field is required.\"\x3e*\x3c/span\x3e\x3c/label\x3e\n \x3cdiv class=\"filefield-element clear-block\"\x3e\x3cdiv class=\"widget-preview\"\x3e\x3cdiv class=\"imagefield-preview\"\x3e\x3cimg src=\"http://vs.localhost/sites/localhost/files/imagefield_thumbs/1/1e0657_chandra_closeup_labeled_3.jpg\" /\x3e\x3c/div\x3e\x3c/div\x3e\x3cdiv class=\"widget-edit\"\x3e\x3cinput type=\"hidden\" name=\"field_observation_sampmeth_photo[0][fid]\" id=\"edit-field-observation-sampmeth-photo-0-fid\" value=\"202\" /\x3e\n\x3cdiv class=\"form-item\" id=\"edit-field-observation-sampmeth-photo-0-data-alt-wrapper\"\x3e\n \x3clabel for=\"edit-field-observation-sampmeth-photo-0-data-alt\"\x3eAlternate Text: \x3c/label\x3e\n \x3cinput type=\"text\" maxlength=\"80\" name=\"field_observation_sampmeth_photo[0][data][alt]\" id=\"edit-field-observation-sampmeth-photo-0-data-alt\" size=\"60\" value=\"Photo of our sampling method.\" class=\"form-text imagefield-text\" /\x3e\n \x3cdiv class=\"description\"\x3eThis text will be used by screen readers, search engines, or when the image cannot be loaded.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-field-observation-sampmeth-photo-0-data-title-wrapper\"\x3e\n \x3clabel for=\"edit-field-observation-sampmeth-photo-0-data-title\"\x3eTitle: \x3c/label\x3e\n \x3cinput type=\"text\" maxlength=\"500\" name=\"field_observation_sampmeth_photo[0][data][title]\" id=\"edit-field-observation-sampmeth-photo-0-data-title\" size=\"60\" value=\"Photo of our sampling method.\" class=\"form-text imagefield-text\" /\x3e\n \x3cdiv class=\"description\"\x3eThe title is used as a tool tip when the user hovers the mouse over the image.\x3c/div\x3e\n\x3c/div\x3e\n\x3cinput type=\"hidden\" name=\"field_observation_sampmeth_photo[0][list]\" id=\"edit-field-observation-sampmeth-photo-0-list\" value=\"1\" /\x3e\n\x3cinput type=\"submit\" name=\"field_observation_sampmeth_photo_0_filefield_remove\" id=\"edit-field-observation-sampmeth-photo-0-filefield-remove\" value=\"Remove\" class=\"form-submit\" /\x3e\n\x3c/div\x3e\x3c/div\x3e\n \x3cdiv class=\"description\"\x3eUpload the photo you took of your sampling method. It should help everyone see the method you used to collect data. No faces. Just nature please.\x3cbr /\x3e\r\n\x3ca href=\"/help/choosing-your-best-sampling-method-photo\" class=\"vst_help_link\"\x3eChoosing your best sampling method photo \x3c/a\x3e\x3c/div\x3e\n\x3c/div\x3e\n\x3c/div\x3e\x3cscript type=\"text/javascript\"\x3ejQuery.extend(Drupal.settings.ahah, { \"edit-field-observation-sampmeth-photo-0-filefield-upload\": { \"url\": \"/filefield/ahah/vs_observation/field_observation_sampmeth_photo/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-observation-sampmeth-photo-0-ahah-wrapper\", \"selector\": \"#edit-field-observation-sampmeth-photo-0-filefield-upload\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"op\": \"Upload\" } }, \"edit-field-observation-sampmeth-photo-0-filefield-remove\": { \"url\": \"/filefield/ahah/vs_observation/field_observation_sampmeth_photo/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-observation-sampmeth-photo-0-ahah-wrapper\", \"selector\": \"#edit-field-observation-sampmeth-photo-0-filefield-remove\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"field_observation_sampmeth_photo_0_filefield_remove\": \"Remove\" } }, \"edit-field-obs-photo-ev1-0-filefield-upload\": { \"url\": \"/filefield/ahah/vs_observation/field_obs_photo_ev1/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-obs-photo-ev1-0-ahah-wrapper\", \"selector\": \"#edit-field-obs-photo-ev1-0-filefield-upload\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"op\": \"Upload\" } }, \"edit-field-obs-photo-ev1-0-filefield-remove\": { \"url\": \"/filefield/ahah/vs_observation/field_obs_photo_ev1/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-obs-photo-ev1-0-ahah-wrapper\", \"selector\": \"#edit-field-obs-photo-ev1-0-filefield-remove\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"field_obs_photo_ev1_0_filefield_remove\": \"Remove\" } }, \"edit-field-obs-photo-ev2-0-filefield-upload\": { \"url\": \"/filefield/ahah/vs_observation/field_obs_photo_ev2/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-obs-photo-ev2-0-ahah-wrapper\", \"selector\": \"#edit-field-obs-photo-ev2-0-filefield-upload\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"op\": \"Upload\" } }, \"edit-field-obs-photo-ev2-0-filefield-remove\": { \"url\": \"/filefield/ahah/vs_observation/field_obs_photo_ev2/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-obs-photo-ev2-0-ahah-wrapper\", \"selector\": \"#edit-field-obs-photo-ev2-0-filefield-remove\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"field_obs_photo_ev2_0_filefield_remove\": \"Remove\" } }, \"edit-field-obs-photo-ev3-0-filefield-upload\": { \"url\": \"/filefield/ahah/vs_observation/field_obs_photo_ev3/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-obs-photo-ev3-0-ahah-wrapper\", \"selector\": \"#edit-field-obs-photo-ev3-0-filefield-upload\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"op\": \"Upload\" } }, \"edit-field-obs-photo-ev3-0-filefield-remove\": { \"url\": \"/filefield/ahah/vs_observation/field_obs_photo_ev3/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-obs-photo-ev3-0-ahah-wrapper\", \"selector\": \"#edit-field-obs-photo-ev3-0-filefield-remove\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"field_obs_photo_ev3_0_filefield_remove\": \"Remove\" } } });\x3c/script\x3e" }

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:

Fatal error: Call to undefined function image_gd_check_settings() in /[sitepath]/includes/image.inc on line 70 

So.. why isn't imagefield using imageapi functions?

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

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.

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_pic..." 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 and Memory Limit (let's use ini_set('memory_limit', '256M'))

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

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.

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.1x. Every other report I've received in the past 4 months has been configuration related.

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)

  var options = {
    ...
    complete: function(response, status) {
      if (status == 'error' || status == 'parsererror') {
        return ahah.error(response, ahah.url);
      }
    },
    ...
  };

  // Bind the ajaxSubmit function to the element event.
  $(element_settings.element).bind(element_settings.event, function() {
    $(element_settings.element).parents('form').ajaxSubmit(options);
    return false;
  });
  

This ahah.error fires in Opera, but not in Firefox.

Arguments for function complete(response, status):

status: "error" in Opera, vs "success" in Firefox,
response.status: 0 in Opera and Firefox,
response.responseText: '' (or null) in Opera vs '...........' (long text) in Firefox
response.esponseXML: [object HTMLDocument] in Opera and FF

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

      setTimeout(function () {
        i.appendTo("body");
        j.attachEvent ? j.attachEvent("onload", cb) : j.addEventListener("load", cb, false);

j is an iframe.
In Opera it seems that the onload event fires too early, before the iframe content is loaded.

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.appendTo("body");
      setTimeout(function () {
        j.attachEvent ? j.attachEvent("onload", cb) : j.addEventListener("load", cb, false);

This allows the timeout to do its job. The iframe will load with empty content, before the onload event is attached. Then the onload event is attached, the event fires again, this time with the real content that we are interested in.

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.

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

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!

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?

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?

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 Error 0 occurred (on file upload)
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

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.

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

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?

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.

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.

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 when creating admin_thumb for the ImageAPI support.

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.

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.

I reviewed #157 as suggested.

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

My issue looks like a). The error comes up as soon as I click "upload."

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?

It seems to happen anywhere there is an "upload" or "attach" option/button, including ImageField, FileField, and the upload module, at least as far as I have tested--but only after the "upload" or "attach" button is used.

- Will the image upload be successful if you submit the entire form, without clicking the "upload" button?

In each case, it seems to upload just fine, as long as I don't click "upload" or "attach" before submitting.

- what exactly happens: are you redirected to a different page? does the button disappear?

No redirect. The button disappears and I get a whole lot of gobbledygook in its place.

- does it happen in all browsers?

It happens in Firefox, IE, and Safari. In Opera, I get a small popup with the "HTTP error 0 occurred" message, and I can't go beyond that.

- does it happen on a localhost drupal install with very high memory limit?

It does not happen at all on my localhost copy site, though it has the exact same memory limits as my live site.

- does it help to replace jquery.form.js with the new version?

That didn't help my situation, or change anything.

- very interesting: does the upload form on this issue queue work for you?

The upload form on this issue queue works just fine for me.

#163 && #162
I opened a new drupal site with image field (that worked) in the same server near to the one I'm talking about and checked my php configurations before i wrote it. I don't know if this is a server configuration problem in my case.

For what it's worth, I'm having this problem both locally and on a Dreamhost account only in FF 3.5.5, but not in IE or Chrome. Although on another site it only happened locally, but I do not know where the site was hosted.

Have the same problem with Opera 10, but works ok with IE6 and Firefox 3.0

I think that imagefield javascript has a cross-browser compatibility issue.

Subscribe

Happens to me with Opera 10 , FF 3.5 and not in IE 8

An interesting wrinkle... I get this error when the node/add page is in a pageroute. Outside of the pageroute - same cck type - no error.

Apache error log shows:

PHP Fatal error: Class 'Page' not found in /home/.../sites/all/modules/pageroute/pageroute.route.inc on line 299

Look up to #158 for my situation. Something worked for me although it was not pretty.

I had made a list of what I had yet to try. It included the following:

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 reinstalled imagefiled, imagefield_crop, and filefield. This did the trick. I did not reinstall imagefield_crop since this is where things went wrong in the first place. However, all data that was installed using imagefield_crop was deleted which is to say the vital database data connecting images to nodes. This freaked the user out... but at least they could now upload images again.

You might try doing what I did as well as the other two on the list. The third did not work for me either.

The end.

I was experiencing a similar issue to the one reported, an HTTP 0 error every time I tried to upload an image into an imagefield. What was really puzzling me was that it worked fine on my main site, but my online store is in a separate subdomain and I got the error 100% of the time there.

After a big of digging I got wondering if the fact that the store is configured to do its edits via HTTPS might be the problem. A bit more digging got me thinking that maybe a tweak to the Secure Pages config would solve the issue.

Sure enough, all I had to do was add one line to the "Ignore Pages" field:
filefield/progress/*

Now the upload progress shows as expected. Just thought I'd report it here in case anyone having the same issue might benefit from the same fix.

That sounds like a fine job of troubleshooting... word to the wise though... you can end up in a mixed mode if your reference that path as http during an https session. This may bring up an 'secure and unsecured' objects warning especially in Internet Explorer which may scare some customers away.

Greets, similar behaviour here, tried different combinations of modules/browsers:
Opera 10, gives the error (with devel, fckeditor enabled/disabled).
Firefox 3.5 allows upload (devel/fckeditor enabled/disabled).
Opera 10 correctly uploads the information if the "Save" button is clicked (instead of "Upload").
No change for the php memory_limit (128M), or the cache minimum time to live. Dimensions seem to be irrelevant.

Will try Dragonfly (opera debugger) to see... what there is to see... =)

Have you tried the following?

* reinstalling the filefield, etc modules... not disable/enable... full reinstall one at a time...
* using the new jquery.form.js file
* "Will the image upload be successful if you submit the entire form, without clicking the "upload" button?"

This error was encountered just using the core file attachment feature, and with the PECL progress meter enabled.

Popup appears with the following text:

An HTTP error 0 occurred.
/upload/js

Problem went away after restarting Apache. I also noticed php-pear package was out-of-date, and upgraded it.

Our LAMP environment (after update):
Ubuntu Intrepid
Apache/2.2.11 (Unix) DAV/2 PHP/5.2.6-2ubuntu4.5 with Suhosin-Patch configured
php5-common 5.2.6-2ubuntu4.5
php-pear 5.2.6-2ubuntu4.5
uploadprogress 1.0.0

php.ini:
upload_max_filesize = 300M
post_max_size = 310M
memory_limit = 128M
max_execution_time = 30

I will report back if this problem recurs after php-pear update.

I'm having this problem too, restarting apache didn't solve the problem and I have the latest version of php-pear and php5

my php.ini settings are:

upload_max_filesize = 500M
post_max_size = 500M
memory_limit = 350M
max_execution_time = 30

Regarding this: "Will the image upload be successful if you submit the entire form, without clicking the "upload" button?"

The image gets uploaded.

Where is the new jquery.form.js?

EDIT: Removing an image gives me: "An error occurred. /rootofdrupal/filefield/ahah/content_type_name/field_image/0
(no information available)."

The new jquery is here: http://jquery.malsup.com/form/#download

Have you tried reinstalling potentially problem modules like filefield, imagefield, imagefield_crop, etc?

@wickedskaman I'm creating a distribution so everytime I dump the database and install the site is like reinstalling, I'll try the new jquery. Thanks

I tried uninstalling filefield and imagefield and is just not working even with the new jquery.form.js

I am having the same issue with the version I downloaded today (and drup 6.14), though it does appear that the image is being uploaded. Does this have anything to do with the /ahah/ path? I tried to manually create that path, but that did not help.

I have reverted back to 3.1 which works fine.

I found the source of my problem, it's the RDF module, when I enable RDFa I get the error. Can anyone confirm what DOCTYPE you're using since this might be the cause.

Mine is this one:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
  "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">

It might be related to #476280: RDFa setting breaks json output of some modules and ahah functionality of cck buttons

I just wanted to report that a post over in the filefield issue discussion led me to disabling all my Greasemonkey scripts in Firefox, which eliminated the http error 0 for me. After many frustrating days. So simple (in this particular case).

this issue is happening to me on D6.15 UC2 latest versions as of now, all plugins up to date.
it was an upgrade from the latest D5UC1. but i tried a totally fresh install with imagefield and its dependencies only, same behavior.
memory is set to 256. php max upload and max post set to 64

behavior:
this is happening with all imagefields including newly created ones.
not happening with the upload module's file attachments.
no disappearing form elements it is just an error on hitting upload.
if i do not touch the upload button and just submit the page, i get a blank page and the node did not save. this is the same as if i disable javascript (with files over 2.7mb).
on one xp box Opera, FF 3.5 and IE 8 all throw the error but only on files over 2.7MB.
but on another xp box, the error is thrown for EVEN SMALLER files (90K), and a downgrade to FF3.0 did not help. disabling javascript on this computer allows files up to 2.7 mb to be uploaded.
opera throws the error immediately.
on ubuntu with FF3.56, or epiphany, the error happens with files over 2.7mb.

i have tried (besides a fresh install):
different themes. disabled clean-urls
flushed all caches on drupal and on client browsers.
turned off page compression.
reinstalled cck, filefield imagefield
replaced jquery.form.js (should i install jquery form update module?)

i enabled pecl upload progress and i got a meter instead of the spinner, but the upload still stops at about 2.6 mb (98%) and throws the usual error.

in conclusion, on some computers i can't upload even a small image, and on other computers i can't go past about 2.6 mb.

ah, i thought FF meant firefox. haha. ok so, in filefield and imagefield is it safe to downgrade?
are there any differences in the db between 6x-3.1 and 6x-3.2?
so far, on a test site, downgrading fixes the problem. my uploads no longer cut off at 2.75mb. testing the other computers.

This is a very good point. How many others subscribing to this have tried downgrading with success?

well i just re-updated them to 3.2 and when i ran update.php it said 0 of 0, and no queries were run.
then i downgraded again, no problem.
the disconcerting thing is that once upgraded, i didn't have any problems!
maybe it has nothing to do with file sizes.

i just tried another image that is smaller, it fails, but not with an http error, it gets to 98% then the progress bar says "starting upload" and then it just hangs there. clicking "add another item" does nothing after that, and saving the page returns a blank page. shrinking this image slightly fixes the problem, but i am uploading larger images without an issue. this is true of 3.1 and 3.2 (no more http error on this computer).

tests on another computer show that nothing has changed, and they are still getting the http error.
so i guess the downgrade did not actually help.

http://drupal.org/node/529958 related? but that is the upload element module.
or this: http://drupal.org/node/473760 ?

here is a new behavior. if i change the field's widget to "file upload" instead of "image", then i can upload the files that normally fail, however, only the ones that normally don't fail show up in "view" mode. when i go to edit, the ones that normally fail are still there. none of them have thumbnails in edit mode with that widget.

tried fupload, jifupload and imagefield import, and with certain images i am having similar behavior: bank screen on page reload, etc. so i think this is a combination of problems. on some computers the upload is not working at all, and then with some images, something is crashing after the upload, so maybe resolution plays a factor. probably there are three or four things going wrong at once.

can anyone help me debug this in a way that is useful?

replacing the upload widgit with jifupload (nicer) or fupload modules solves the problem on computers that couldn't even upload small images. so that is a potential FIX.
they also allow the larger images to be uploaded but which then seem to be crashing imagecache (WSOD) or something when you try to edit the node. view node works.
php memory is now 512. tried both image toolkits. no errors in apache logs. limiting the resolution on the image field doesn't help either.

some related errors in the drupal logs:

imagecache already generating
and
imagecache non-existent action

but since the wsod issue isn't a http error like the issue describes, i will find a new home for those inquiries.

Hi everybody,

I had the same problem with images until .... now :p

The problem occured suddenly so i could find the problem by tracing what I have done. (i put a backup and it worked ;) ).

My problem was :

First : { "status": true, "data": "\x3cdiv class=\"messages error\"\x3e\nThe file in the image field was unable to be uploaded.\x3c/div\x3e\n\x3cdiv id=\"edit-field-image-0-ahah-wrapper\"\x3e.... when i uploaded an image

Second, images alias didn't work anymore : the image didn't display...

I was sure the problem was due to max_execution_time that I reduced in php.ini the day before ,but when I set back the old value, nothing changed.... :S
If you didn't changed your php.ini, there is no reason that the problem come from php.ini.... see what did you change.

But when, i put back the backup, all worked ! so I put my backup file by file and finally I have found the file problem !
I still didn't found the problem so I have replaced line by line .... :)

In fact, my image problem was ........ an encoding problem !!!!

My file was changed to UTF-8 instead of UTF-8(sans BOM), so I had some wrong character :s

But i don't understand how image and encoding are linked !!

So, if your problem arrived suddenly, I suggest you to put back a backup and check if works and then replacing, step by step, file by file, line by line :p

Good luck !!

Hey all,

Just a quick addition to this. I had the same problem with imagefield and upload module, only in firefox.
I tried all of the above disabling greasemonkey plugin, re-installing modules (properly), increasing memory limit, etc.
Then tried a different copy of firefox on a different machine, it worked. Long story short, turns out my problem
was the linkification plugin. I just disable this now and all is well.

Strange, it happened all of a sudden, worked previosly with this plugin enabled. So anyone else gets thisproblem, add
disabling ALL firefox plugins, from Tools -> Add-Ons to the list of attempts to fix above.

Seems like this is quite a broad error from the above discussion.

Thanks for this thread and your help.

/Paul.

Guys even m a victim of d same problem
if i upload the pic den it shows http0 error
but if i dont upload it and just save it den it seems to work fine
help me i have to submit this website n 3 daz or else i wud hv to pay d penaltyyyyy

robin, please use complete sentences and proper grammar when posting. I'm sure the solution to your problem has been mentioned somewhere in this post already. As noted, 99% of the time it's server or Drupal configuration. It's not a bug in ImageField.

FEEDBACK

I'm running Drupal 6.15 on localhost (xampp). I had the very same problem but only under Opera 10.10 browser. So, I followed this:

http://drupal.org/node/603826#comment-2217002

Replace misc/jquery.form.js with a newer version found here: http://jquery.malsup.com/form/#download

It worked like a charm, again, on Opera 10.10

Just faced this problem with Opera 10 on Linux. Memory limits were high, normal uploads worked ok, and error reported was instant, so it become clear that it's client/browser problem. File replacement described in #114 fixed problem for me. Thanks donquixote!

UPDATE: My case is #612754: JS upload broken in Opera 10.1x

I have the same problem as mentioned in this post (and several others).

When trying to upload an image I get an alert box saying "HTTP error 0 occurred". The file gets uploaded so I guess it's not a permissions issue. I have testet this in different browsers/versions on several machines both PC and Mac.

There error occured after I updated to filefield 6.x-3.2 and imagefield 6.x-3.2. I have a similar site running on the same host (basically a copy) where I didn't update the modules and this still works fine.

As far as I know I have tried everything in the posts:

* Manual update of the jquery.form.js
* PHP settings is set correctly
* Disabled FCKEditor
* Removed FCKEditor
* Installed jQuery update
* Tried different images

Hope someone got other ideas I might try out. And if you need more information please let me know.

I had the same error, using a dedicated server and ModSecurity. 16 minutes of google and I found a page that described TROUBLE SHOOTING ERRORS using ModSecurity:

This shows up in my error log (server) Message: Request body (Content-Length) is larger than the configured limit (131072)

I edited my apache2.conf and changed SecRequestBodyLimit (which default is 128kb), SecRequestBodyLimit now has the same value as php upload limit.

That worked for me. Maybe this could be useful for others.

Hi have this same very annoying issue. My settings are as follows...

memory_limit=3072M
upload_max_filesize=256M
post_max_size=1024M

Should not be memory issue. I can upload images of 2048x2048 for Ubercart (imagecache does several resizes for this). I can't do 4k images though (4096x2160) without getting this message. Not sure whats causing it. Any ideas?

Update:

After trying some other stuff (uploading with another user than admin, deactivating modules etc.), I tried changing the widget type of the field to file instead of image. Now I can upload (without a preview though) so the error is probably connected to the image type/preview somehow. I actually tried this before but I did not realize that it would still display the file as an image.

So for now problem solved, even though the image type widget still does not work.

I also think its related to the thumbnail when you try to upload it. I can see the file transfers but I still get the error and its not attached to the node. I tried uploading the two images. Both around 3.5MB with the attach tool. One works, one just sits there indefinitely. This happens every time I try it so it must be related to the upload module as well.

UPDATE

It looks like if the file does manage to upload I get this:

HTTP error 0

filefield/ahah/product/file_field_cache/0

Hello
This fixed it for me:

I had Problem Version a). In Opera the Error came immediatly after clicking the upload-button. I am running the latest drupal6 on the latest Xammp on Windows7, local.

- To fix the error i enable the php_uploadprogress.dll in php ini and restarted Apache. This did not help.
- I made the post- and memory-settings MUCH higher in php.ini. Restarted apache. This did not help.
- I also replaced the jquery.form.js in drupal/misc/ with the patched version as mentioned above. This did not help.
- I also disabled the filefield and imagefield-modules. cleared cache. re-enabled the modules, ran update.php etc.. This did not help.

- I followed the advice a few posts above, installed the jQuery-Updater module. Upon installation it asked me for a setting, and i chose to let it download the "minified" packages. I gave it a cron-run and checked in /admin/reports/status. There it said jQuery Update Version 1.2.6. After that the uploads (with progressbar) work fine.

I can't tell you, if it was just the last measure (jQuery-Updater module) that fixed it or the combination of all the above.

Best of luck to you all having this time consuming problem,
Stephan

hey sorry quicksketch if you had a problem
anywaz i got it fixed
i just removed that upload button
and now it's working fine

Well the problem i was having was that
whenever i browse the picture and then i hit upload and then i go on saving the node... it used to show a horrifying error
but if i JUST browse the picture and then don't hit upload button and save the node... i get no error and the picture is posted well
Hence what i did is that i just removed the upload button

Hello All,

I am facing this problem only when i use the administrator account to upload files. If I use some other account that has the permissions to upload files, it works fine. However, please note that in my case, i am using cck field upload, in which i upload huge mp3 like 20 - 50 MB. I am not sure if the same problem is there with the image uploads, or the normal upload modules.. The only thing i can say is that the 'administrator' account in my case fails to upload my mp3 files using the file upload module.. Using other account works fine.. The idea to use other account came from the following link that has some code to fix the administrator upload problem.. I am not sure how did this person realize this problem and even wrote the code.. I have not used the code..

http://drupalbin.com/9320

Hope this helps in identifying the problem..

Thanks..

I'm having the problem only in Opera. Like you, I find saving without uploading works fine. My question is, how do you remove the upload button?

Does this help? It seems to be related.

warning: array_filter() [function.array-filter]: The first argument should be an array in /home/allthing/public_html/sites/all/modules/image/contrib/image_attach/image_attach.module on line 349.

Subscribing

Subscribing

I have last version of "devel module" 6.x-1.x-dev (2010-Feb-14).
Disabling it solves my problem.

subscribing

I've tried disabling the devel module - this has not stopped the 'An HTTP error 0 occurred. /fupload/js/imagefield' error. I'm running image_fupload 6.x-3.0-rc2

Should this issue be transferred to the 'image_fupload' project?

Should this issue be transferred to the 'image_fupload' project?

No, keep this issue in the ImageField queue. If you're having problems with image_fupload, go search or file an issue in that queue.

I also got the same error "An HTTP error 0 occurred. /filefield/ahah/content_press/field_image/0"

I had FCKeditor installed. So when the error came i opened firebug console to find the following error

document.getElementById(fckLaunchedTextareaId[i]) is null
[Break on this error] if ( document.getElementById( fc...areaId[i] ).style.display == 'none' )

Disabling the FCKeditor worked for me. I have to find out an alternative editor i think so.(maybe TinyMCE)

hello there,

I am experiencing the same problems. Is there any progress on this? There are 200+ comments on this bug report, is there anyone who can still see the trees in the forest? =)

Maybe someone who knows what this is all about can update the bug description with a summary to reflect current status or where people can help out ..?

thanks

For what it's worth, I just had the HTTP Error 0 problem... Wasted the last half hour debugging it.

Seems to be a browser problem to me; didn't work in Chrome, does work in Firefox 3.6.

I tried using json_encode (by tweaking drupal_to_js to return json_encode($var);) but that made no difference... Chrome's inspector thingy reported that there was a JSON response initially:

{ "message": "Starting upload...", "percentage": -1 }

But then the next response is just blank/emtpy after it posts the file to http://example.com/filefield/ahah/product/field_image_cache/0

Very confusing - maybe there is an issue with the way the javascript targets and disables the upload button from fully submitting the form?
(Server settings are fine - upload, post_max and memory_limits are not a problem).

It is true that the error does not appear if you do it this way, but also removed the option to add other images, in the case of multiple images.

Umm seriously? No idea/fix to this? I'm a complete newbie with a fresh install and tried to upload an image. Same problem. Tried disabling progress bar in exchange for throbber, worked once and automatically went back to progress bar selection. There is really very little info that I can find on how to use all these image modules in the first place, Image, ImageCache, Majick or whatever, I don't know exactly what the options do or whats best to select but I did my best. Just trying to add a simple photo to a story. Why is that hard? And php.ini. I have no such file. So yeah, I can create one, what should be in it? I have no idea besides them memory lines that people keep posting here. I doubt thats enough. Contact my host. I did, they referred me to a page to "instruct" me on how to create the file........with zero information. I mean really. And on my cpanel it TOLD me to contact them to reset it. I'm very frustrated right now, can you tell? Its just a stupid photo!!!! But I'll need this fixed before I can do anything else!!!

yes, it can be unbelievable, but I believe it is because somehow not everybody is experiencing this problem? It must be hosting related? I have root access to my server and can change all the mem values you want, but I still could not fix this issue..

If this really is caused by some progress bar stuff, I'd happily disable that in order to have my uploads working. But it did not find the time yet to examine the code.

I encountered this problem in Firefox and disabling the Linkification extension solved the problem for me.

Ok.
One year of bug and neither the users or developers could solve this.
I could find a way to solve it. But I think that this would work only with my case. Why? there's why:
I use two fields: the field A is an ImageField, and the field B is an Image FUpload field, that is nothing more than a field with many images. (I know, FUpload uses ImageField).
When I select the image of the field A, I must click in the UPLOAD button right after the file input, right? http://img7.imageshack.us/img7/9916/picture4vxd.png
Right below is the bulk upload field for B: http://img532.imageshack.us/img532/6505/picture5r.png

If I just select the file for A, and do not click in the upload button, the error will appear to me.
If I select the file for A, click in the upload button for A, and then upload the images for B and click in the save button below the entire form. Will work like a charm.

Hope it can help the develop team to solve this. One year... no excuses.

Hope it can help the develop team to solve this. One year... no excuses.

That's because (as I've said before again and again), EVERY person that has posted later has found out that it was a problem: A) Caused by another module or B) Caused by their server configuration. I can't help that people want to upload 8 MB photos directly from their camera to a shared hosting account on GoDaddy. :P

I personally run ImageField on hundreds of sites that I've put together, and used FileField I've tested uploading up to 1.5 GB files. It works.

I think there is some confusion because similar issues happen with other modules (core upload), and there are different things that can trigger it..

I have not seen this bug for some time myself, but this doesn't mean anything.

Worst thing is, there is no easy way to find out what exactly caused the problem, and thus we get very unuseful bug reports.
Would it be possible to improve error reporting? And reduce the damage if the ajax upload fails?

I think we just need someone to backport this patch to D6:
#646694-18: AJAX: Terrible reporting of status 0 response from AJAX request ("HTTP Error 0 has occurred")

This nice patch wont work in D6? Well, I'll try. No matter how many people have tried.

We have more of this kind, with different modules, and with different causes. I think tagging is a good idea to get an overview.

Turning off Greasemonkey resolved this error for me as well. No clue why, but it works.

Turning off Greasemonkey for me did not effect the error. However, everything works fine in IE so I'm using that to upload products to ubercart.

I tried module with core upload, image upload, itweak upload, Image Fupload, all have the same problem....
with the http error 0 occured and if click save directly without the clicking the upload button it become:

{ "status": true, "data": "\x3ctable id=\"upload-attachments\" class=\"sticky-enabled\"\x3e\n \x3cthead\x3e\x3ctr\x3e\x3cth\x3e\x3c/th\x3e\x3cth\x3eDelete\x3c/th\x3e\x3cth\x3eList\x3c/th\x3e\x3cth\x3eDescription\x3c/th\x3e\x3cth\x3eWeight\x3c/th\x3e\x3cth\x3eSize\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-93-remove-wrapper\"\x3e\n \x3cinput type=\"checkbox\" name=\"files[93][remove]\" id=\"edit-files-93-remove\" value=\"1\" class=\"form-checkbox\" /\x3e\n\x3c/div\x3e\n\x3c/td\x3e\x3ctd\x3e\x3cdiv class=\"form-item\" id=\"edit-files-93-list-wrapper\"\x3e\n \x3cinput type=\"checkbox\" name=\"files[93][list]\" id=\"edit-files-93-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-93-description-wrapper\"\x3e\n \x3cinput type=\"text\" maxlength=\"256\" name=\"files[93][description]\" id=\"edit-files-93-description\" size=\"60\" value=\"25181_404979776966_686201966_4912946_785682_n.jpg\" class=\"form-text\" /\x3e\n \x3cdiv class=\"description\"\x3e\x3csmall\x3ehttp://www.swapcheck.net/swapcheckz/sites/default/files/25181_4049797769...\x3c/small\x3e\x3c/div\x3e\n\x3c/div\x3e\n\x3c/td\x3e\x3ctd\x3e\x3cdiv class=\"form-item\" id=\"edit-files-93-weight-wrapper\"\x3e\n \x3cselect name=\"files[93][weight]\" class=\"form-select upload-weight\" id=\"edit-files-93-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\x3e94.38 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\"\x3eAttach new file: \x3c/label\x3e\n \x3cinput type=\"file\" name=\"files[upload]\" class=\"form-file\" id=\"edit-upload\" size=\"40\" /\x3e\n\n \x3cdiv class=\"description\"\x3eThe maximum upload size is \x3cem\x3e1 MB\x3c/em\x3e. Only files with the following extensions may be uploaded: \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=\"Attach\" class=\"form-submit\" /\x3e\n" }

If Drupal cannot upload file, CMS will be no use....This will jeopardize the whole drupal system and its community if it is not fixed soon.......
I already heard a few people said drupal is bad because it cannot upload file........
The file I upload is just 10kb, 1 file only.
The broswer is Firefox 3.5+, chrome2+
testing platform
both linux and windows

ALL NOT WORK!!!

subcribing

I had the same problem with this error in all browsers (IE, chrome, firefox). Also I noticed that I have two tmp directories in the root of my drupal installation. At the same time I increased memory limit and deleted the more recent tmp directory and it fixed my problem.

same error :(

UPD: cavern links checker was causing this

subscribing

Pls. see also my note #88 to #240777: Attach: An HTTP Error 0 occurred (on file upload).

subscribing

rtbox in #20 is the man.

I've had this problem on this one particular site (of my many), and it was crazy frustrating. I've been in and out of every proposed solution to no avail. During my umpteenth read through this thread, I finally found the nugget that solved this issue for me: Enable Drupal's core Upload module.

Once I did that, ImageField (again, finally) worked as expected in uploading the files and generating thumbnails on the fly.

I'm going to keep my fingers crossed, however.

#111 Seems to fix it for me. Not sure if it will come back though as many seem to have the problem again and again! http://drupal.org/node/434394#comment-2199670

About a week ago, we started seeing "An HTTP 0 error occurred". We confirmed that the files were actually being uploaded, but the end users were seeing the error. We tried the following:

- update jquery.form.js
- increase php.ini settings for memory_limit, post_max_size, upload_max_filesize

None of these worked.

Ultimately, we tracked it down to a line of output that one of our developers added to our site to address a security issue.

<script type="text/javascript">document.domain = "ourdomain.com"</script>

Once we blocked this from being added to the admin pages, the error stopped appearing. This was a bit obscure, but I spent a good deal of time tracking it down, so hopefully it will help someone else.

I was surprised finding this error only on a specific template: in garland template error disappeared.

I can detect the problem in my template.php, in an output statement (echo $string;) in hook_theme implementation (function mytemplate_theme()). I removed it and now everything works fine.

I suggest to try uploading image in a different template.

@donquixote Thanks bro!
Guys, read carefully comment #157 and all will work for you!

My problem was nginx, which was installed as frontend for apache2.
string "client_max_body_size 20M;" solved my problem!

I hit this error last Thursday on my host. Posted it in the Views Gallery issue thinking it was Views gallery at fault. Got no responses. So did a bit of googling and stumbled upon the heap of posts. So here are my experiences and responses to the Troubleshooting list

#157
Troubleshooting List
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).
d) does this only happen with ImageField, or also with FileField, the upload module, or other modules that allow to upload files?
e) Will the image upload be successful if you submit the entire form, without clicking the "upload" button?
f) what exactly happens: are you redirected to a different page? does the button disappear?
g) does it happen in all browsers?
h) does it happen on a localhost drupal install with very high memory limit?
i) does it help to replace jquery.form.js with the new version?
j) very interesting: does the upload form on this issue queue work for you?

My answers
a) With FF 3.5.9 I get a server side issue - (b)
b) With Opera 10.10 I get the client side issue - (a)
c) answered by (a) and (b)
d) Happens only with ImageField only.
e) No redirects to a blank page
f) See response (e)
g) Yes happens in FF 3.5.9 and Opera 10.10
h) Did not try this.
i) Did not try this.
j) Did not try this. But read #28

See My response to #115 below for not trying (h), (i), (j).

Trying out the solutions in the following order (the one that is easy to implement, first!)
#8 and #9 - Creating a temporary Folder in PUBLIC_HTML or WWW. - Did not work
#10 - Setting 'Minimum Cache Lifetime' Administer|Site Configuration|Performance to one minute. Did not work.
#206 - Saving the Node without uploading the image - Doesn't work. Redirects to a blank page.
#115 - Reducing File Size - Works
My original file size was 1.3 MB and I used GIMP to reduce the quality to 1% so the file size was 39KB. I still had a problem uploading it. I then tried to upload a image whose size was 20.2KB. Succeeded. I guess the tipping point is a filesize somewhere between 20.2KB and 39KB. (Due to dimensions or due to the pixel density? I am not sure)

Yet to try the following solutions to see if I will be able to upload file sizes of 1.3MB and above
#240 - Uploading using a different template
#34 - Using ImageMagick
#199 - Installing JQuery Update Module
#22 - Comment Out the ahah wrapper thus disabling the JavaScript Uploader
#165 - Changing File field module
#241 - where do we put the client_max_body_size 20M in the settings.php?
#4 - Increasing post_max_size and upload_max_size in settings.php
#17 - Changing PHP memory in settings.php to 96M
#16 - Fixing mod_security issue to allow inheriting rules for path/filefield

My localhost setup
------------------
Ubuntu 9.10 Karmic Kaola
FireFox 3.5.9 (lot of addons including Firebug)
Opera 10.10
No FCKEditor
No RDFModule
No Throbber

My hostserver
-------------
PHP Memory 32MB

Tried #17 (my hosting service provider was kind!)

I changed the PHP memory settings using the .htaccess and PHP.ini to 64M I an able to upload images upto 1.3MB. I 've made no other changes.

I get the solution yesterday, when i installed the : http://drupal.org/project/jquery_form_update
And everything is OK now, i can upload files and no problems appear.

Having the same problem in chrome fine in IE anyone any suggestions, tried the jquery update and no good. Its not a file size issue as it works in chrome.

I think its a bit poor saying its not the file upload fields fault, a lot of people on here would not have a clue where to start with this issue and I have to say for a CMS thats sells itself as piss easy to use I have had to do a lot of searching and spend a lot of time getting solutions to problems. Fine if its not the the file fields fault post up the solutions to what the various causes are, all I see on here are lot frustrated people trying each others suggestions.

**UPDATE**

If its chrome issue you are having install the jsalter module and then the jquery_form_update, solved it for me.

So guys,

I got the problem too. Drupal and CCK are the newest. I installed the jsalter and jquery_form_update_modules. My Server has 128M max_memory_size. I tried with FF 3.6.4, Chrome 5.0375.55, IE 8. Everytime I click the uploadbutton I get the error.

I use the multistep module and if I use the save button after selecting the image it works. If I use the add another item button the form disappears and after refreshing i get 'this node is edited by another user and is locked'.

If I try to use 'upload' and click 'next' I get an access denied message.

I used throbber and pecl uploadprogress. no difference.

ah yeah, disabling javascript is working :P

In my case it was a problem with multistep. there is a patch #833696: FileField in a Field Group problem available.

I was getting the same error 'HTTP error 0 occurred' on image upload, my drupal(6.17) status report was blaming the memory limit which was set to 64MB on a shared hosting account. I upped this to 128MB and the problem changed from giving an error in a popup on upload of the image to a white screen error on saving the node.

The new error said something else about memory, so I upped the memory more, and the bang, the error was gone.

My problem turned out to be some home-rolled js in a block that wasn't set to not appear on any page.

The fix was to simply add a "show on every page except these: "node/add/*" and "node/*/edit".

Wa-bam.

I just had this problem when switching from low res to hires photo images - less them 1meg in size -

[From a previous post in this thread]

switching ImageAPI from GD2 to ImageMagick appears to solve it for me

I was going to say that actually, if you're getting a 500 server error, it probably isn't related. This issue seems to mainly generate the WSOD.

Alas Misters, but has dared the full pulling down of a site and setting anew...

+ subscribe

+1

"Reducing File Size": only solution that worked for me till now.

I have this error on 3 different sites I'm working on. All 3 are on different server environments, 2 different hosts. Dedicated server here in town, Media Temple dedicated virtual server and Media Temple grid service. All are at various stages of core and module updates, from 6.16 to 6.19. All 3 have the HTTP error 0 when trying to upload. The newest site had FileField installed, but not yet ImageField, and was already giving me the error.

For me, size or file type, file or image, are irrelevant. Zen subtheme or Garland both give the error. FileField 3.1 and 3.7 both give the error. I installed PECL uploadprogress on the newest site's server and can see the files starting to upload before they die. Rules out permissions. Firefox and IE both give the error.

Here's the weird part. One client initially started having the error in FF (which they were primarily using), but was still able to upload in IE. After a few days, it stopped working in IE. Also, their error message said something about their small file being larger than the 8M upload limit, but I get the HTTP 0 error message here. And if I try it on another machine at work that I don't usually use, the uploads generally work. Very, very weird.

The ONLY thing I have found that allows me to upload successfully once I start getting the error is to disable Javascript in my browser, which is not ideal for a client.

I also get the error trying to upload to this forum.

I really, really hope that contributing yet another batch of clues to this forum thread will trigger an idea for a solution. This is progressively becoming a BIG problem for me on ALL of my sites.

Thanks everybody!

What's your php upload limit set to? (Are theyall the same?)

For the newest site (which is pretty empty and basic and am using for testing this issue) it was set to 2M by default. I upped it to 96M. Didn't help.

I've got this issue on Opera 10.61. FF 3.6.8 works good.
For me installing JQuery Update Module solved the problem. Opera 10.61 and FF 3.6.8 (and IE8) works good. I can upload images up to 1.41mb.
PHP vars memory_limit=128mb, upload_max_filesize=2mb and post_max_size=8mb.
Before installing module I've tried updating jquery.form.js to last version (2.47) and some older versions, but it only made worse - error popup started to show on FF, which worked fine before (2.47) or made error popup disappear but cause endless "loading" icon on Opera (older versions).

I always get this error with FF 3.6.8 but I never get this with any other browser IE, Chrome, Opera

my FF is loaded with billions of plugins and I thought it could be related

If this is a server configuration issue, then why do some of our Drupal sites have the problem (2) and some (17) don't have the problem? Same server. Same configuration. Same php.ini.

Drupal 6.19
Using the core File Upload module ("File attachments")
Uploading a tiny (4kb) text file (.txt)
PHP memory limit: 128M
Error occurs in both Firefox 3.6.9 and Safari 4.0.5

php.ini says:
file_uploads On
upload_max_filesize 10M

Things I've tried that did not work:
changing the image upload file size from 800 x 600 to 0 and back
checking permissions on files, files/css and files/js
turning css compression and js compression on and off
installing and enabling jQuery Update module
disabling and re-enabling the File Upload module
enabling the IMCE module and using it for file uploads
adjusting user-specific file upload limits
checking file upload size limits in php.ini
Update to latest jQuery Form Plugin
Check to make sure display_errors != On in php.ini

It's not always a "server" configuration problem, sometimes it's Drupal. Like having Devel module display statistics or the Memcache Admin module doing the same thing. Or theme developer tool breaking nearly all JavaScript. I can say, it's not a problem with FileField, it's other modules irresponsibly breaking JSON requests, or (still a very likely cause) server configuration on the PHP/Apache side.

Wow, this also worked for me too. Used a dirty hack previously which removed the javascript.
This method worked for me perfectly.

Big Pepper Design

I had a Drupal upload (image upload or attachment upload) issue. Might also look like a CCK imagefield issue. Here what helped me:

http://www.sitebuddy.com/drupal-error/upload-image-attachment

Good luck,
Christophe
PS: Spent our hours reading these threads with no solution.

Subscribing.

Installed the content taxonomy field module and the whole image field uploading broke down. Worked just fine before that. Hosting doesn't mention any works, so I trust them on that (although I did have some FTP problems earlier today. Might ask them 'bout that tomorrow and see if anything did change).

I tried turning off the content taxonomy field module, but the problem persists.

Tried updating all modules (Drupal core and CCK were outdated). With the updates (both in uploading files and running updates.php), the problem's still there.

It's in both Firefox (3.6.3) and IE 8, so it's not browser-specific here.

Firebug doesn't catch any errors, even with literally all errors turned on.

Downgraded JQuery from 1.4.2 to 1.3.2 and it works again.

funny, i downgraded from 1.3.2 to 1.2.6 and it works again ...

subscribe - getting same root error as first post.

I was running jquery 1.4.2 from the latest version of JQuery Update, and received this error. I fixed it by applying the patch in this thread: http://drupal.org/node/479368

Hi everyone!
Maybe someone will get rid of this.
I have done the common mistake of putting the "?>" (close php code section) at the end of my template.php. After removing it the problem was gone ))
So first of all - try to switch to one of standard themes.

'Ajax' module was causing this for me. Disabled the module and all good.

Subscribing - users on my site are having lots of trouble with this error as well. As the imagefield is a required field for creating the node, users are stuck and unable to create the node.

Same error when using UberCart MarketPlace running on Drupal 6.19 on FireFox. Image is only 13kb. I am trying to upload a product image.

Although, I was able to upload images elsewhere on the website using the same module, a custom CCK form.

I also recently installed and enabled the Content Taxonomy Module 6x 1.0 rc2 like (#266). I tried disabling the module but the error still persists.

An HTTP error 0 occurred.
/drupal/filefield/ahah/services/field_image_cache/0

Increased php.ini to 64MB from 32MB. Error still persists.

I hit my head against the wall for a while fighting with this same problem and would like to pass on another possible solution:

in my case it was an apache issue, not related to drupal or the modules in use.
LimitRequestBody in the apache config for the server was set too low, so apache was resetting the connection part-way through the upload.

Increasing that value in the config for just the site I was having the problem with solved it.

Would this fix address the issue in that image uploads don't work with UberCart Marketplace, but uploads work elsewhere (CCK form) ?

Also, I am running XAMPP on a Windows machine would you be able to explain how I can access the Apache config, please?

Thanks

adding JQuery Update module and making sure I had correct permissions set on the upload directories sorted it for me when I was migrating an existing site to a new server. Thanks for the assistance everyone.

I am getting the same error. When I view the apache error log file,/usr/local/apache/logs/error_log for me ,I find this info ' PHP Fatal error: Call to undefined function field_file_urlencode_path() in /var/www/html/sites/all/modules/imagefield/imagefield.module on line 377'.There isn't a field_file_urlencode_path function in all modules,but luckly,I find the answer:upgrade to FileField 3.9 ,see http://drupal.org/node/997150.

Good Luck.

junfeng.tan,

So upgrading to version 6x. 3.9 did fix your issues for FileField? Did you have the same issues with ImageField too? Did upgrading that module help too?

Thanks

junfeng.tan's problem was upgrading to ImageField 3.9 but not to FileField 3.9. You always have to upgrade ImageField and FileField at the same time to the matching versions. For the most part, upgrading to 3.9 version will not help the problem for most users, since the problem is usually a server configuration problem or another module is mangling the AJAX requests.

Yes! I am building an Ubercart site.At the beginning,I installed the filefield module 6.x-3.1 and imagefield module 6.x-3.9,so i get the same issues when I upload a product image.When upgrading the filefield module to 6.x-3.9,i solve the problem.

We are also seeing this error and are perplexed. Per #157, we are in camp b)

b) With the server-side issue, you have to wait for the error message to pop up.

We've tried with jQuery 1.3 and 1.4 and with filefield/imagefield updated to 6.x-3.9. We have tried disabling just about everything but can't get to the bottom of it. When trying to upload an image to a billboard content type we see a request to:

http://dev2.XXXXXX.com/filefield/ahah/billboard/field_ddblock_if_image/0

and the header that comes back is:

http://dev2.XXXXXX.com/%22http:////dev2.XXXXXX.com//sites//default//file...\%22

and the files DO exist in that directory.

We can upload images using normal upload like users can update their user pictures on their user edit page just fine. Any help would be MOST appreciated!

Some more info, here's the content of the response from that filefield/ahah call:

{ "status": true, "data": "<div  id=\"edit-field-picture-0-ahah-wrapper\"><div class=\"form-item\" id=\"edit-field-picture-0-wrapper\">\n <label for=\"edit-field-picture-0\">Picture: <span class=\"form-required\" title=\"This field is required.\">*<\/span><\/label>\n <div class=\"filefield-element clear-block\"><div class=\"widget-preview\"><div class=\"jcrop-preview-wrapper\" style=\"width:600px;height:400px;overflow:hidden;\"><img src=\"http:\/\/dev2.golfzing.com\/sites\/default\/files\/test_6.jpg.crop_display.jpg\" alt=\"jcrop preview\" title=\"\" class=\"jcrop-preview\" \/><\/div><script type=\"text\/javascript\">jQuery.extend(Drupal.settings.imagefield_crop, { \"edit-field-picture-0\": { \"box\": { \"ratio\": 1.5, \"box_width\": 800, \"box_height\": 800 }, \"minimum\": { \"width\": \"600\", \"height\": \"400\" }, \"preview\": { \"orig_width\": 300, \"orig_height\": 250, \"width\": 600, \"height\": 400 } } });<\/script><\/div><div class=\"widget-edit\"><input type=\"hidden\" name=\"field_picture[0][fid]\" id=\"edit-field-picture-0-fid\" value=\"2756\"  \/>\n<input type=\"hidden\" name=\"field_picture[0][data][crop][x]\" id=\"edit-field-picture-0-data-crop-x\" value=\"0\"  class=\"edit-image-crop-x\" \/>\n<input type=\"hidden\" name=\"field_picture[0][data][crop][y]\" id=\"edit-field-picture-0-data-crop-y\" value=\"0\"  class=\"edit-image-crop-y\" \/>\n<input type=\"hidden\" name=\"field_picture[0][data][crop][width]\" id=\"edit-field-picture-0-data-crop-width\" value=\"300\"  class=\"edit-image-crop-width\" \/>\n<input type=\"hidden\" name=\"field_picture[0][data][crop][height]\" id=\"edit-field-picture-0-data-crop-height\" value=\"200\"  class=\"edit-image-crop-height\" \/>\n<input type=\"hidden\" name=\"field_picture[0][data][crop][changed]\" id=\"edit-field-picture-0-data-crop-changed\" value=\"1\"  class=\"edit-image-crop-changed\" \/>\n<div class=\"form-item\" id=\"edit-field-picture-0-data-description-wrapper\">\n <label for=\"edit-field-picture-0-data-description\">Description: <\/label>\n <input type=\"text\" maxlength=\"128\" name=\"field_picture[0][data][description]\" id=\"edit-field-picture-0-data-description\" size=\"60\" value=\"\" class=\"form-text\" \/>\n<\/div>\n<div class=\"form-item\" id=\"edit-field-picture-0-cropbox-wrapper\">\n <label for=\"edit-field-picture-0-cropbox\">Crop area: <\/label>\n <img  class=\"cropbox\" id=\"edit-field-picture-0-cropbox\" alt=\"\" src=\"http:\/\/dev2.golfzing.com\/sites\/default\/files\/test_6.jpg.crop_display.jpg?1294527885\" \/>\n<\/div>\n<input type=\"hidden\" name=\"field_picture[0][list]\" id=\"edit-field-picture-0-list\" value=\"1\"  \/>\n<input type=\"submit\" name=\"field_picture_0_filefield_remove\" id=\"edit-field-picture-0-filefield-remove\" value=\"Remove\"  class=\"form-submit\" \/>\n<\/div><\/div>\n <div class=\"description\">Upload your photo here (you can crop the photo after uploading).<\/div>\n<\/div>\n<\/div><script type=\"text\/javascript\">jQuery.extend(Drupal.settings.ahah, { \"edit-field-picture-0-filefield-upload\": { \"url\": \"\\\/filefield\\\/ahah\\\/group_photo\\\/field_picture\\\/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-picture-0-ahah-wrapper\", \"selector\": \"#edit-field-picture-0-filefield-upload\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"op\": \"Upload\" } }, \"edit-field-picture-0-filefield-remove\": { \"url\": \"\\\/filefield\\\/ahah\\\/group_photo\\\/field_picture\\\/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-picture-0-ahah-wrapper\", \"selector\": \"#edit-field-picture-0-filefield-remove\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"field_picture_0_filefield_remove\": \"Remove\" } } });<\/script>" }