Drupal 6.4
CCK 6.x-2.0-rc6
FileField 6.x-3.0-alpha3
Imagefield 6x-3.0-aplha1

Using the admin account I am able to insert images into content using Imagefield. When a non-admin account submits an image, a pop-up error message displays "An HTTP error 0 occurred. /filefield/ahah/page/field_image/0' where page and field_image are part of the naming scheme. Drupal's log shows this as an access denied error, so I believe this is a permissions problem.

This error occurs with and without a custom path specified in the field. All permissions checked for the non-admin account does not fix the problem. The file path is set to the default 'sites/default/files' and downloads are set to Public.


cucat’s picture

Me too, i got the same error ! Please help us.

webernet’s picture

Status:Active» Closed (duplicate)
amaltheos’s picture

#297035: HTTP error 0

Apparently I did not look hard enough. Thank you very much!

petiar’s picture

But that is a patch for FileField. I can not see mentioned code in ImageField module. Any suggestions? I am getting the same popup error message.

Sorry, I did not realize ImageFiled depends on FileField. I have patched FileField and now it works, thanks a lot!

Thank you very much.

drewish’s picture

update to the latest versions of the filefield and imagefield modules. i just created a release yesterday that fixes the bug.

rowdypostman’s picture

I'm having this same issue... seems to be a resizing problem. If I upload an image that is pretty small, no problem. If I upload a larger image (still below the maximum file size, however), this pops up.

SOLVED: the issue for me was a memory_limit in php.ini set to 64M. I upped this to 100M and that fixed the problem. For really large files 64M isn't enough memorey for GD to do resizing.

Benj’s picture

Stan.Ezersky’s picture

You need to create a tmp folder in /public_html or /www

drupalninja99’s picture

Version:6.x-3.0-alpha1» 6.x-3.1

I am getting this error so I am going to try the php.ini trick, anything else I should look at doing?

fattmox’s picture

We too experienced this issue in Drupal 6 - it has mutliple causes but this is what did it for us.

AHAH was working fine in test and staging environments but not in production. The difference we tracked down after a very depressing week was the 'Minimum cache lifetime' under Admin->Settings->Performance. We set this to and all was well. Hope this helps someone else out there from a week of hitting the head on the wall.

hypatia7777’s picture

What did you set the Minimum Cache Lifetime to?

mrgoltra’s picture

Me too, I don't know if this will help troubleshoot the problem. I had to change the widget type from image to file upload and the error was gone. When I changed the widget type back to image I got this error

Fatal error: Call to undefined function image_gd_check_settings() in /home/mysite/public_html/includes/image.inc on line 70

scifisi’s picture

Same problem.

I have memory_limit = 128M the latest version of ImageField and FileField. I have a /tmp directory will full access permissions and I get this error even if I'm logged in as Admin...

Any one with any ideas?

k74’s picture

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

PECL not installed

the-sandman’s picture

Same issue with Opera 10.Firefox and Internet Explorer works.

Are there any ideas?

brazorf’s picture

It seemed like a mod_security issue in my own case, so i fixed denying inheriting rules for path /filefield.

Basically, i noticed that every ajax/ahah related error popup, without regard about the http error, is about a 406 http error and mod_security configuration. I came to this by skipping the "Upload" ahah button and just saving my node by submitting the entire form: it gaves to me a 406 http error.

Hope this helps

GiorgosK’s picture

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

and problem was solved

tolland76’s picture


I am seeing this error, but only when the admin using tries to upload files, it works fine for authenticated users. any ideas?


GiorgosK’s picture

This is probably a duplicate of this as well
#434394: 'HTTP error 0 occurred' on image upload

Marko B’s picture

I dont think this is memory issue. this problem is all over filefield imagefield and image zip. I set mine to 512 MB and still there is error 0.

merzikain’s picture

My problem isn't with memory either. I increased it from 128M to 5G and still no joy. I have recently increased the php post_max_size and upload_max_filesize to 750M (we deal with sharing large image files with clients) yet it seems there's some other limit set somewhere that is keeping me from uploading anything larger than 8M (the original limit before increasing it to 750M). The form and phpinfo() both show that the settings are 750M yet there is some limit somewhere that isn't allowing anything larger than 8M.

Running this on IIS 6 and so far my googling for a solution isn't producing one. I'm going to continue but was wondering if anyone had some insight that might make my task any easier.

sunchaser’s picture

Man alive ... this might have been the longest I've looked for a problem.

I did EVERYTHING suggested , nothing helped, untill I went hardcore on the module :)
This solution was partly inspired by a solution that suggested to downgrade to filefield module alpha 2 release, cause there , the problem didn't occur.

I wanted to know what made the difference between the two releases and stumbled upon filefield_widget.inc
in that file, around line 271 there was something remarkeable going on.

The lines that provided the ahah wrapper where commented out !

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

So, what I did to work things out was :

  1. Just install the latest version of the Filefield module
  2. Open up filefield_widget.inc with a texteditor
  3. and comment out the lines above.

If anyone can shed some light on to what this does and if this kills other functionalities that I'm not aware of, let me know.
But I just have to do it this way, cause nothing else would work.

Marko B’s picture

Does this solves problem? Are images uploaded now without problem?

Michali’s picture


Your fix with commenting out those lines also fixes the problem for me. Thanks. :)

Hanno’s picture

fixes the problem for me as well.

Images are uploaded without a problem, however I have the following side effects:
- The effect to fade in the image thambnail is gone
- after clicking upload, if the title is still empty, he warns me that there is an empty node title
- removing the image gives an error.

Marko B’s picture

Think imagefield or whole this construction around filefield/imagefield AHAH is not reliable, developers keep saying there isnt any bugs but i keep getting problems all around on different sites in different situations. Seems that everything is bothering this upload and all it gives all the time is this stupid error 0 and its like you need dedicated server to upload few pics grrrr. You can find this error 0 issue on
Its said its FCK problem or DEVEL problem or memory problem or i dont know what problem, but seems that a lot ppl are getting mixed results, if developers are sure its DEVEL module problem than state in installation, you must disable devel module for this to work or something like that as most of us will use devel module and test stuff with it and have it NOT work than, hate i have to think about switching to image module and try it for solution as this is so tiresome with all this ZERO problem. :-(

gvelez17’s picture

Thanks, sunchaser. The commenting out worked for me. I also commented out a similar block in the 'filefield_remove' array, this may solve the problem reported above with error on removing an image.

I had been having the HTTP error 0 problem with filefield-6.x-3.3 and imagefield-6.x-3.3

lolmaus’s picture

I've just had the issue on a shared hosting. It would not upload files larger than ~1MB. The hosting had PHP memory limit of 10MB.

Same website migrated to my own dedicated server with generous server settings has just let me upload a ~3MB image with no error.

Balbo’s picture

#22 doesn't work for me. I don't have anymore the "http error 0" but browser keep on loading and image never got uploaded...

Dirk’s picture

I love you and want to have your babies, finally! a solution that worked, however hackish.

This was on an openatrium (beta8) site BtW, if anyone else using that platform is having the same issue.

Incidentally, this only works, for me, with the jquery and jquery.form files that came with Drupal 6.19. I had attempted to upgrade those earlier, a solution that has worked for me before, but in this case they interfered with the working solution.

EDIT: this was meant as a reaction to comment #22

valderama’s picture

On my install the problem was a browser add-on for firefox, namely "Inline Translation".

As I was working myself through some issues, I generated this troubleshooting checklist for this error:

* issue can be browser related
** disable inline translator add-on
** on google chrome disable "smooth scrolling"
* disable javascript for better error reports
* can also be an php setting, file_size related stuff
* disable memcache and devel module

Marko B’s picture

Are developers of this module aware of our problems?
Seems to me like they ignorig this issue as its a bug that appears under specific curcomstances that appear many times in working inviroment but probably not on some blank testing sites.

m.sant’s picture


drupal fan’s picture

problem solved with

** on google chrome disable "smooth scrolling"

thanks a million "valderama"

reinderdevries@gmail.com’s picture

I would like to mention that this bug on my system was actually caused by including jQuery 1.4.2 instead of the Drupal-provided 1.2. Maybe this knowledge helps someone.

ericG’s picture

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.

Marko B’s picture

There should have been some fallback method for uploading images, as many people reported this 0 error. Would rather have module without AHAH then to have so many problems with this error 0

tinny’s picture

An HTTP error 0 occurred.

Problem specific to firefox.
Works on chrome, safari, ie (IE for gods sake).

In firefox:
If i disable javascript it works.

If i add an image by saving instead of uploading first, i get this:

{ "status": true, "data": "\x3cdiv id="edit-field-prod-pic-large-0-ahah-wrapper"\x3e\x3cdiv class="form-item" id="edit-field-prod-pic-large-0-upload-wrapper"\x3e\n \x3cdiv class="filefield-element clear-block"\x3e\x3cdiv class="widget-preview"\x3e\x3cdiv class="imagefield-preview"\x3e\x3cimg src="http://localhost/sites/default/files/imagefield_thumbs/images/products/large/18_1.jpg?1291963147" title="18.jpg" alt="Image preview" /\x3e\x3c/div\x3e\x3c/div\x3e\x3cdiv class="widget-edit"\x3e\x3cinput type="hidden" name="field_prod_pic_large[0][fid]" id="edit-field-prod-pic-large-0-fid" value="1737" /\x3e\n\x3cdiv class="form-item" id="edit-field-prod-pic-large-0-data-alt-wrapper"\x3e\n \x3clabel for="edit-field-prod-pic-large-0-data-alt"\x3eAlternate Text: \x3c/label\x3e\n \x3cinput type="text" maxlength="80" name="field_prod_pic_large[0][data][alt]" id="edit-field-prod-pic-large-0-data-alt" size="60" value="" 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\x3cinput type="hidden" name="field_prod_pic_large[0][list]" id="edit-field-prod-pic-large-0-list" value="1" /\x3e\n\x3cinput type="submit" name="field_prod_pic_large_0_filefield_remove" id="edit-field-prod-pic-large-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.ahah, { "edit-field-prod-pic-thumb-0-filefield-upload": { "url": "/filefield/ahah/product/field_prod_pic_thumb/0", "event": "mousedown", "keypress": true, "wrapper": "edit-field-prod-pic-thumb-0-ahah-wrapper", "selector": "#edit-field-prod-pic-thumb-0-filefield-upload", "effect": "fade", "method": "replace", "progress": { "type": "throbber" }, "button": { "op": "Upload" } }, "edit-field-prod-pic-thumb-0-filefield-remove": { "url": "/filefield/ahah/product/field_prod_pic_thumb/0", "event": "mousedown", "keypress": true, "wrapper": "edit-field-prod-pic-thumb-0-ahah-wrapper", "selector": "#edit-field-prod-pic-thumb-0-filefield-remove", "effect": "fade", "method": "replace", "progress": { "type": "throbber" }, "button": { "field_prod_pic_thumb_0_filefield_remove": "Remove" } }, "edit-field-prod-pic-small-0-filefield-upload": { "url": "/filefield/ahah/product/field_prod_pic_small/0", "event": "mousedown", "keypress": true, "wrapper": "edit-field-prod-pic-small-0-ahah-wrapper", "selector": "#edit-field-prod-pic-small-0-filefield-upload", "effect": "fade", "method": "replace", "progress": { "type": "throbber" }, "button": { "op": "Upload" } }, "edit-field-prod-pic-small-0-filefield-remove": { "url": "/filefield/ahah/product/field_prod_pic_small/0", "event": "mousedown", "keypress": true, "wrapper": "edit-field-prod-pic-small-0-ahah-wrapper", "selector": "#edit-field-prod-pic-small-0-filefield-remove", "effect": "fade", "method": "replace", "progress": { "type": "throbber" }, "button": { "field_prod_pic_small_0_filefield_remove": "Remove" } }, "edit-field-prod-pic-large-0-filefield-upload": { "url": "/filefield/ahah/product/field_prod_pic_large/0", "event": "mousedown", "keypress": true, "wrapper": "edit-field-prod-pic-large-0-ahah-wrapper", "selector": "#edit-field-prod-pic-large-0-filefield-upload", "effect": "fade", "method": "replace", "progress": { "type": "throbber" }, "button": { "op": "Upload" } }, "edit-field-prod-pic-large-0-filefield-remove": { "url": "/filefield/ahah/product/field_prod_pic_large/0", "event": "mousedown", "keypress": true, "wrapper": "edit-field-prod-pic-large-0-ahah-wrapper", "selector": "#edit-field-prod-pic-large-0-filefield-remove", "effect": "fade", "method": "replace", "progress": { "type": "throbber" }, "button": { "field_prod_pic_large_0_filefield_remove": "Remove" } } });\x3c/script\x3e" }

Then i refresh that error page and i get this error:
{ "data": "\x3cdiv class="messages error"\x3e\nAn unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (128 MB) that this server supports.\x3c/div\x3e\n" }

the uploaded file was 21kb....

then i click 'back' and save the node again and the images get uploaded.

SO frustrating. This happened all of a sudden too. I already uploaded lots of content before and it worked fine. Now........

EDIT: FIXED: i used #22 fix and it worked. the thing is though, i UNDID the fix and now it still works. so i commented out ahah array in the filefield_widget.inc file then i UNcommented them and now it works.... what is this i dont even...
EDIT: NOT FIXED: it doesnt work again.

ieyara’s picture

In my case, the prolem was the memcache statistics that were appened at the end of every paga. I disable this debug option and the problem was fixed.

jallenb’s picture

Updating FileField to 3.9 resolved it for me. See http://drupal.org/node/997150 for details.

marazmus’s picture

I've found yet another solution with "HTTP Error 0 upload/js" problem.

If you have Nginx http-server as frontend with Apache as backend (very useful scheme, and this using in ISP Manager server software), search in /etc/nginx/nginx.conf (Nginx config file) for "client_max_body_size" directive.

If you have not found it, just add this line in http { section:

client_max_body_size 32m;

Where 32M - max upload file size in your php.ini file.

By default, if you have no client_max_body_size directive in your nginx.conf, Nginx will drop any uploading flle that have more than 2M size, and you'll get this weird HTTP error 0!

agmin’s picture

Confirmation: jquery 1.4.2 breaks filefield. Using the jquery update module (jquery 1.3.2) works fine.

davestormuk’s picture

I just applied the latest Jquery update, no difference.

davestormuk’s picture

I can confirm, this worked for me.
Posted by agmin on December 29, 2010 at 9:19pm

Confirmation: jquery 1.4.2 breaks filefield. Using the jquery update module (jquery 1.3.2) works fine."

gianfrasoft’s picture

I solved in a strange way but I did!

Please, take a look at this:


oferrero’s picture

If you are using nginx as a proxy, the comment #29 may solve your issue:

Basically add the following settings to nginx.conf's HTML block:

client_max_body_size 32M;
client_body_buffer_size 128k;
aterchin’s picture

yeah it's 1.4.2 jquery breaking it. sucks.

Todd Young’s picture

What's recommended fix for the majority at this juncture?

introfini’s picture

After disabling the jQuery Update module the problem went way. So, its definitely something to do with jQuery.

mailfox’s picture

#22 it`s work for my in solution pageroute

defconjuan’s picture