Original message:

When I upload a file, it alerts an window and says /[path]/filefield/ahah/[content type]/field_[field_name]/0

Update, after almost 300 comments:

This error can be caused by many, many different things (it's almost always a configuration problem). Here are some of the standard fixes that have been reported in this thread or elsewhere:

  • Check the permissions of your 'files' folder, make sure they're correct.
  • Check PHP's memory_limit, max_upload_size and other limits and try increasing them to see if that resolves the problem.
  • If you're using GD for images, try switching to ImageMagick... and make sure it's configured correctly. A quick check of your status report page should show which one you're using and whether it's working.
  • Switching the upload progress display for a file or image field from a bar progress meter to a throbber might help.

As I said above, though, there are literally hundreds of different things that can cause this error. Good luck!

Comments

p.s

6.x-3.0-alpha3 has problems
6.x-3.0-alpha2 is ok
6.x-3.0-alpha1 is ok

I have this problem too....
Can someone tell me what is this filefield-ahah-wrapper...

Same problem. Also happens when you try to remove an uploaded file, and when logged in as an admin user. Just recently upgraded to Drupal Core 6.4...don't think that's the issue though.

Same issue here. Important to note that only occurs in non admin account. Have all permissions set correctly. Alpha3 is essentially broken.

Apparently, someone the filefield module is still working. If you don't click the update button, but instead, preview or save. It wont use the broken code.

I can confirm what other people are experiencing. I rolled back from alpha 3 to 6.x-3.0-alpha2 and it is fixed the problem.

Same here. Even after setting ALL PERMISSIONS to new user.

I don't have time to look into this just now, but subscribe.

subscribe

Same problem....subscribe

As I can see the problem is in filefield_menu():

<?php
   
'access callback' => 'filefield_edit_access',
   
'access arguments' => array(2),
?>

should be
<?php
   
'access callback' => 'filefield_edit_access',
   
'access arguments' => array(3), // here
?>

Because filefield_edit_access() operates $field_name but [content type] passed instead.

The patch will be ready soon.

Status:Active» Needs review
StatusFileSize
new624 bytes

The patch.

Thanks, it fixes now!

If at first it doesn't work, clear Drupal cache, clear browser cache and then reload the form.

Thanks for the patch!

Component:Miscellaneous» Code
Status:Needs review» Reviewed & tested by the community

Vladimir's patch is correct, and you will need to clear Drupal's menu cache for it to take effect.

thanks, committed to HEAD.

Status:Reviewed & tested by the community» Fixed

Sorry to bring up a fixed issue but I have installed the latest dev version and it works with every browser I have tried (other comptuer with both internet explorer and firefox) it on except my main browser (firefox), what do I need to do to so it uses the new version of FileField?
I have tried clearing both the cache of firefox and my drupal site and still nothing.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

good afternoon, i am having the same problem. I have version 6.x-3.0-alpha4, which have the code already fixed.
I get the same error trying to upload any image to fields created with filefield/imagefield. i can upload posts attachments with any problem. Is there any configuration that can affect this module?
thanks,

gb

Assigned:oxhead» lierrework
Status:Closed (fixed)» Needs work

if "Path settings" -> "[date-in-tz]" - if name of date not in english - directory have bad name and we have... this error

Hello,
----updated
I have checked the path and set to [user], just in case. The system behaves the same, get an error :
An HTTP error 0 ocurred
/peslab/filefield/ahah/work/field_thumb/0
were 'peslab' is the sitename; 'work' is the content type and 'field_thumb' is the field. The weird thing is that there is not such a path in my installation.
I can can see the file uploaded in the server (in "sites/default/files/admin'), but all uploads i am trying with filefiled returns the same error.
Any suggestion??

Thanks,

gb

When filefield's AHAH callback isn't replying with valid info like this you *should be getting a PHP error in your server logs. I would check there to see what's tripping up the call.

thanks moonshine, but i have no php entries in the error log. Maybe a js issue?
i have tried several browsers (ie 6, firefox 3 mac os and safari) with no success.
I am new to drupal and i don't know how to continue. Shall i install a previous version of filefield/imagefield to see if it works?

Are you running CCK Fieldgroup Tabs by chance?

No, just the module Fieldgroup (version 6.x-2.0-rc7)

Priority:Critical» Normal
Status:Needs work» Postponed (maintainer needs more info)

need a clear set of steps that i can use to reproduce this error. try disabling the devel module if it's enabled.

I have the same error with 6.x-3.0-alpha5 and 6.x-3.x. when i hit "save", the following throws on the screen:

{ "status": true, "data": "\x3cdiv class=\"ahah-new-content\"\x3e\x3cdiv class=\"form-item\" id=\"edit-field-photo-0-wrapper\"\x3e\n \x3clabel for=\"edit-field-photo-0\"\x3eProperty Photo: \x3c/label\x3e\n \x3cinput type=\"hidden\" name=\"field_photo[0][fid]\" id=\"edit-field-photo-0-fid\" value=\"18\" /\x3e\n\x3cimg src=\"http://74.220.219.69/~roddyinc/sites/default/files/CalvinOnHorse_1.jpg.t...\" /\x3e\x3cdiv class=\"form-item\" id=\"edit-field-photo-0-data-description-wrapper\"\x3e\n \x3clabel for=\"edit-field-photo-0-data-description\"\x3eDescription: \x3c/label\x3e\n \x3cinput type=\"text\" maxlength=\"128\" name=\"field_photo[0][data][description]\" id=\"edit-field-photo-0-data-description\" size=\"60\" value=\"\" class=\"form-text\" /\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-field-photo-0-list-wrapper\"\x3e\n \x3clabel class=\"option\"\x3e\x3cinput type=\"checkbox\" name=\"field_photo[0][list]\" id=\"edit-field-photo-0-list\" value=\"1\" class=\"form-checkbox filefield-list\" /\x3e List\x3c/label\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-field-photo-0-upload-wrapper\"\x3e\n \x3clabel for=\"edit-field-photo-0-upload\"\x3eReplace: \x3c/label\x3e\n \x3cinput type=\"file\" name=\"files[field_photo_0]\" accept=\"jpg,jpeg,png,gif\" class=\"form-file\" id=\"edit-field-photo-0-upload\" size=\"60\" /\x3e\n\n \x3cdiv class=\"description\"\x3eMaximum Filesize: \x3cem\x3e2 MB\x3c/em\x3e\x3cbr /\x3eAllowed Extensions: \x3cem\x3ejpg jpeg png gif\x3c/em\x3e\x3cbr /\x3eMust be a JPEG, PNG or GIF image\x3c/div\x3e\n\x3c/div\x3e\n\x3cinput type=\"submit\" name=\"op\" id=\"edit-field-photo-0-upload-btn\" value=\"Upload\" class=\"form-submit\" /\x3e\n\x3cinput type=\"submit\" name=\"field_photo_0_remove_btn\" id=\"edit-field-photo-0-remove-btn\" value=\"Remove\" class=\"form-submit\" /\x3e\n\n\x3c/div\x3e\n\x3c/div\x3e\x3cscript type=\"text/javascript\"\x3ejQuery.extend(Drupal.settings, { \"basePath\": \"/~roddyinc/\", \"admin_menu\": { \"margin_top\": 1 }, \"ahah\": { \"edit-attach\": { \"url\": \"/~roddyinc/?q=upload/js\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"attach-wrapper\", \"selector\": \"#edit-attach\", \"effect\": \"none\", \"method\": \"replace\", \"progress\": { \"type\": \"bar\", \"message\": \"Please wait...\" }, \"button\": { \"attach\": \"Attach\" } }, \"edit-field-photo-0-upload-btn\": { \"url\": \"/~roddyinc/?q=filefield/ahah/property/field_photo/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-photo-0-ahah-wrapper\", \"selector\": \"#edit-field-photo-0-upload-btn\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"op\": \"Upload\" } }, \"edit-field-photo-0-remove-btn\": { \"url\": \"/~roddyinc/?q=filefield/ahah/property/field_photo/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-photo-0-ahah-wrapper\", \"selector\": \"#edit-field-photo-0-remove-btn\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"field_photo_0_remove_btn\": \"Remove\" } } } });\x3c/script\x3e" }

Hope that helps someone (who is much smarter than i) figure out what could be going on here.

Maybe it is a rather weird and funny, but.. I have the same situation as cwhitcoe (6.x-3.0-alpha5). I have a gallery site made with imagefield, imagecache and lightbox. I added 1 site - everything was OK with uploading images. Then I made a view site (with views module), wanted to add another site to gallery and I got this error: HTTP: 0. /filefield/ahah ...
But I use Firefox with Greasemonkey and some scripts, when I turned off Greasemonkey, I was able to upload next images without any problems. So try this.

I have the same problem with the version = "6.x-3.0-alpha5" filefield. As administrator I always get an "The Image upload failed" (even when it is technically a file upload).

When the module TinyTinyMCE is enabled I get the same behaviour as noted in this thread; ie. I get a javascript error message, and I get about the same message as #28. I've been turning that module on and off and consistently get the same problem.

It is important to note that regardless the file is not uploaded to the site. The module creates the correct subfolders in the files folder, but nothing is written. The logs doesn't reveal anything, except that the ahah message has been returned. The error log has no error messages while testing with and without TinyTinyMCE.

I've always hat this problem with the filefield 3 series, never got it to work; except once earlier today on an all new installation of xampp at work.

HOW TO RECREATE?
Download xampp-macosx-0.7.4.tar.gz and install in Applications
Change /Applications/xampp/etc/php.ini to accept files of 32M size, max script memory to 128M
Change /Applications/xampp/etc/httpd.conf to allow All in <Directory "/Applications/xampp/xamppfiles/htdocs">
Download Acquia-drupal-1.0.1-ISR.2844.tar.gz
Install drupal.
Activate the content module and Save configuration
Activate the FileField module and save configuration
Make a simple content type "FileUpload" add a file field and try to upload.

Fails every time.

Fails differently on a MacBookPro with 10.4.x vs a Mac Pro with 10.5.x. On the former the files show up in the files directory, but they will not attach to the node. On the latter the files aren't even uploaded.

I'll try 6.6 of Drupal and see if there is any change, then thry alpha4 of filefield for good measure.

It works fine on the hosting I use, I can upload the files there. It seems to be either OSX or XAMPP related. Those of you who experienced this problem could chip in by telling what OS and configuration.

It would be nice to have it working on a local development setup as well.

Version:6.x-3.x-dev» 6.x-3.0-alpha5

I got this error:

An HTTP error occured. /filefield/ahah/datei/field_hplbl_file/0

Can be produced the following way: Select two files and then hit the upload button. If I select one file, upload and then select the other file and upload it just works fine.

Maybe this could be avoided with only displaying one filefield by default.

For XAMPP/LAMP etc, the issue is: http://drupal.org/node/283140

Go into the php.ini file and uncomment upload_tmp_dir and write it as follows:

upload_tmp_dir = /tmp

That should solve the problem for OSX.

Having same ahah error 0

i am trying to create an image gallery using cck, filefield,imagefield,and views. I am using 6.6 Everything else seems to be working.
The following error occurred when preview was clicked:

I am about 6 months into drupal but still on the sucks part of the learning curve. Any help?

{ "status": true, "data": "\x3cdiv class=\"ahah-new-content\"\x3e\x3cdiv class=\"form-item\" id=\"edit-field-image-0-wrapper\"\x3e\n \x3clabel for=\"edit-field-image-0\"\x3eimage: \x3cspan class=\"form-required\" title=\"This field is required.\"\x3e*\x3c/span\x3e\x3c/label\x3e\n \x3cinput type=\"hidden\" name=\"field_image[0][fid]\" id=\"edit-field-image-0-fid\" value=\"16\" /\x3e\n\x3cimg src=\"http://www.kentdev.responseactiondesign.com/sites/default/files/images/1...\" /\x3e\x3cdiv class=\"form-item\" id=\"edit-field-image-0-data-description-wrapper\"\x3e\n \x3clabel for=\"edit-field-image-0-data-description\"\x3eDescription: \x3c/label\x3e\n \x3cinput type=\"text\" maxlength=\"128\" name=\"field_image[0][data][description]\" id=\"edit-field-image-0-data-description\" size=\"60\" value=\"test\" class=\"form-text\" /\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-field-image-0-list-wrapper\"\x3e\n \x3clabel class=\"option\"\x3e\x3cinput type=\"checkbox\" name=\"field_image[0][list]\" id=\"edit-field-image-0-list\" value=\"1\" checked=\"checked\" class=\"form-checkbox filefield-list\" /\x3e List\x3c/label\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-field-image-0-upload-wrapper\"\x3e\n \x3clabel for=\"edit-field-image-0-upload\"\x3eReplace: \x3c/label\x3e\n \x3cinput type=\"file\" name=\"files[field_image_0]\" accept=\"jpg,jpeg,png,gif\" class=\"form-file\" id=\"edit-field-image-0-upload\" size=\"60\" /\x3e\n\n \x3cdiv class=\"description\"\x3eMaximum Filesize: \x3cem\x3e1 MB\x3c/em\x3e\x3cbr /\x3eAllowed Extensions: \x3cem\x3ejpg jpeg png gif\x3c/em\x3e\x3cbr /\x3eMust be a JPEG, PNG or GIF image\x3c/div\x3e\n\x3c/div\x3e\n\x3cinput type=\"submit\" name=\"op\" id=\"edit-field-image-0-upload-btn\" value=\"Upload\" class=\"form-submit\" /\x3e\n\x3cinput type=\"submit\" name=\"field_image_0_remove_btn\" id=\"edit-field-image-0-remove-btn\" value=\"Remove\" class=\"form-submit\" /\x3e\n\n\x3c/div\x3e\n\x3c/div\x3e\x3cscript type=\"text/javascript\"\x3ejQuery.extend(Drupal.settings, { \"basePath\": \"/\", \"ahah\": { \"edit-book-bid\": { \"url\": \"/book/js/form\", \"event\": \"change\", \"keypress\": null, \"wrapper\": \"edit-book-plid-wrapper\", \"selector\": \"#edit-book-bid\", \"effect\": \"slide\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": false }, \"edit-field-image-0-upload-btn\": { \"url\": \"/filefield/ahah/image/field_image/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-image-0-ahah-wrapper\", \"selector\": \"#edit-field-image-0-upload-btn\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"op\": \"Upload\" } }, \"edit-field-image-0-remove-btn\": { \"url\": \"/filefield/ahah/image/field_image/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-image-0-ahah-wrapper\", \"selector\": \"#edit-field-image-0-remove-btn\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"field_image_0_remove_btn\": \"Remove\" } }, \"edit-field-image-1-upload-btn\": { \"url\": \"/filefield/ahah/image/field_image/1\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-image-1-ahah-wrapper\", \"selector\": \"#edit-field-image-1-upload-btn\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"op\": \"Upload\" } }, \"edit-field-image-field-image-add-more\": { \"url\": \"/content/js_add_more/image/field_image\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"field-image-items\", \"selector\": \"#edit-field-image-field-image-add-more\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"field_image_add_more\": \"Add another item\" } } } });\x3c/script\x3e" }

Status:Postponed (maintainer needs more info)» Closed (fixed)

wtf?!?! Ok please do not reopen closed issues. all of you shame... Please open a new issue with a synopsis of everything after the access control issue was closed. Preferable a simple steps to recreate, what happened, and what you expected. With the HTTP 0 thing... try running with JS disabled. often it occurs because something goes wrong on the drupal side, or devel injects a header. The HTTP 0 is a fairly common error for Ajax issues... please don't lump it under on issue.

.darrel.

I am having this problem with Beta5, is there a patch for this in beta5?

I am having the same http0 error, however, unrelated to devel. I am trying to upload images that are 3.5mb (all the php.ini settings are set to 20mb max). If i lower the file size, the upload works perfect, if I try and upload the original image, it barfs with http0 every time.

any help would be appreciated... thanks.

Ok, I fixed my issue after days of looking it at it. I switched to imagemagick instead of gd, and updated the imagemagick toolkit. The error has gone away.

Cheers.

I had this problem with my site, it worked fine on my development server, i moved it to the clients live server and suddenly started getting the error: /[path]/filefield/ahah/[content type]/field_[field_name]/0.

I tested the upload of the image before launching it, but the image i uploaded was a much smaller filesize than the ones the client uses as backgrounds.

Anway the solution for me was handed to me by Drupal itself, it mentioned in the status report that the Memory_limit in php was too low. I dropped this line into my site and bingo it worked ini_set("memory_limit","20M"); If it doesnt work you may need to increase the amount of memory, (please be careful when doing this).

My Drupal Version is: 6.6
My FileField version is: 6.x-3.0-alpha5

Hope this Helps someone

Regards
Luke Tarplin
Web Developer

Version:6.x-3.0-alpha5» 6.x-3.0-alpha6
Status:Closed (fixed)» Postponed (maintainer needs more info)

The same on alpha6.

HTTP: 0
/filefield/ahah/forum/field_user_gallery/0

Why is that?

Downgrading to filefield-6.x-3.0-alpha2.tar.gz helps:)

Status:Postponed (maintainer needs more info)» Fixed

Status:Fixed» Closed (fixed)

Issue still continue here => #329913: still HTTP error 0

Hi moonshine, I'm getting the 'http error 0' message with the latest version of filefield installed (6.x-3.0-alpha6), and I am using CCK Fieldgroup Tabs, is it likely that this is the cause of the problem? I've not been able to fix the error with any of the suggestions listed here / in related postings, and would like to use fieldgroup tabs if possible, but appreciate they are still in dev!
Many thanks,
Chris

I was having the same problem while uploading images to Ubercart.

It turned out the images I were using were abnormally wide (50 inches) and by reducing their size a bit the problem went away.

Here's the error when I apply the patch:

patching file filefield.module
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n] y
Hunk #1 FAILED at 29.
1 out of 1 hunk FAILED -- saving rejects to file filefield.module.rej

Anyone know how to resolve?

Hi

some users of my site reporting this bug when they want to add or replace images.
What is weird that me as admin, or by masquerade as that user can't reproduce this error.
(latest filefiled and imagefield)

Igorik

Version:6.x-3.0-alpha6» 6.x-3.0-alpha7

Hello,

I'm using alpha7 and I have this error even being logged as administrator with Devel module turned off.
It's somehow connected with size of the file and generally is not appearing for files < 1MB...
There is no way to upload a few MB JPGs which... make me sad ;]

Kotu

Kotu: I had the same problem. After hours of debugging I discovered that my php memory limit was set to 32MB. I increased the memory to 512MB and the error went away.

hi guys, i had the same problem.
FCKEditor with attached imagefield worked ok, but after changing fckeditor setup and forced simplified toolbar for body field the http error 0 appeared when trying to upload images.
I think that filefield and fckeditor have some problem together...but not always.
To fix the problem i forced plain text for body field, now i don't have fckeditor and imagefield upload on the same content type.
Hope this helps.

Koto and all,
I'm brand new to Drupal. I got this error uploading my second file. How do I change the PHP limit?
Thanks.

Edit your php.ini and look for the settings.
Read more: http://drupal.org/node/100373
or Google more

I was having the same problem. It seems to have started when I updated Devel module. I disabled Devel module and it started working again. (In case it helps those who were asking, my site is on Windows 2008, IIS 7.)

Same problem here:

Server and config: Drupal 6.10/php 5.1/RHE5; php memory set to 512M w/ only core modules installed + imagefield, cck, and filefield, using Garland as a test theme.

Upload procedure works fine in Firefox: selects file, uploads, previews, saves. Works great.

In Safari (3.2.1) I get the dreaded code dump, the file is uploaded to the server, but no preview, no file saved to the db.

In Opera (9.6.3) I get the same behavior as in Opera.

Nothing changes when I turn off Devel.

On a CentOS server, I can get further w/Safari, but noticed differences in behavior:

Imagefield defined as multiple images. When I go to upload field, get code. However, if I click on the "Add another" button, the image preview magically appears.

I went back and tried to replicate on the RHE server, but when I upload and get the code dump, no preview appears.

No problems at all in Firefox. I'm guessing a java version issue somewhere, but I don't know where to look to figure this one out.

I just realized this was closed. I'll file a new one, with more findings.

After hours figthing, I just disabled FCKeditor and Wysiwyg and now is working normally. Apparently there's an issue with these modules and image_field, also it affected the way image_cache work.

Version:6.x-3.0-alpha7» 6.x-3.0

Just have the same message
After long tests just realize that working on other navigator like midori but not in my Firefox install.

So test firefox plugins one by one and find the usual suspect :
Linkification : http://yellow5.us/firefox/linkification/

To fix it :
- desactivate it or ...
- add your site on the linkification blacklist

Hope it will help ....

I am having this problem in multiple sites, but only when trying to upload with Firefox. I found that after disabling all my addons, the file upload would work. I kept only the webdev toolbar which seems to work fine

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

I had The same Problem again on a drupal 6.* site, but this time not caused by the php memory limit, as that was set fine, firebug was complaining every time i tried to upload a file, when not logged in as user 1, so for example: I am an authenticated user with the permissions to upload files, however it kept giving me the error: An http 0 occurred /upload/js.

Firebug kept complaining about an unknown method call d.submit in jquery.forms.js and after looking at the script it appears that if any form element is named submit or has an id of submit it will fail. So after locating 2 submit elements in seperate forms and renaming them using firebug the file uploaded fine.

The solution i found was to ensure no Javascript errors, this included stripping out the commenting at the head of the jquery.forms.js file as the javascript packing engine was complaining about it. I also went through my hook_form_alter methods in my custom modules and discovered that an element i had altered was being named submit by default within drupal, so i added a '#name' element and this sorted the problem for me.

Quite an obscure one that had me busy for a day.

Kind Regards
Luke Tarplin
Web Developer

I was getting this same exact error. I started to look at what modules I have installed in my FF3.5. In a fresh install of 3.5 and 3.0.10 it worked fine. The first modules I uninstalled was firebug. when it still didn't work I reinstalled it.

I finally came to the ad block plus module. instead of uninstalling it, I just disabled it from the small menu item that it places in the toolbar. It started uploading fine. I do not know if this is an issue with a combination of fckeditor since the page I was testing on did not have a text area that got replaced by fckeditor.

so I think, at least in my case, something in adBlock Plus for FireFox is what is causing my problem. I even turned off the FCKEditor module and it worked with adBlockPlus disabled and not work when it was enabled.

go figure

Nothing works for me. Not one of the 6 browsers memory limits, addons ahhhhhhhhh!!!!!!!!!!!!

Changing the image size a couple of times fixed this. The size has never been an issue before though.

If you're reading this, you're probably as frustrated as I was that this seemed to be a problem with a million solutions - and none. (I.e. tons of specific fixes suggested, but none work.)

Well, I found a million-and-oneth. It was mentioned by no one else here, but it worked for me and it may work for you:

RDF Module (6.x-1.0-alpha7) - I disabled this, and the problem went away.

Slightly more broadly, I just had a think about what I changed between when image uploads worked and when they broke. You might do better with that strategy, rather than searching for "the fix" for this on the forums. Evidence is that there's no "the fix", only "your fix". >^\ Or, put another way, it seems like a lot of things might conflict with filefield.

Good luck!

This problem occurs in reducing resolution of picture.
I tried load image resolution which is bigger that adjusted in parameter for maximum image resolution (600x480).
If is image to limit - all is OK.
If the image is over limit, occurs:

An HTTP error 0 occurred.
/?q=filefield/ahah/report/field_xxx/0

Core 6.13
ImageField 6.x-3.1
FileField 6.x-3.1
Firefox 3.5.1

IE 8.0 hasn't any problem.

I Enabled (PECL uploadprogress)
I increased PHP memory limit from 64M to 256M
Problem gone.
I will test it again with another server.

I just updated to Filefield 6.x-3.1 and Filefield_paths 6.x-1.3, and I'm getting this error a lot with .tar.gz files, files segmented using split, etc.

Is it possible GetID3 is choking trying to determine the file's mimetype? Or that Filefield_meta is having compatibility issues with getID3? I ran some tests and it seems to indicate this. (I'm setup to upload files as big as 1GB, so I know it's not a memory setting.)

Also, on cases that fail with the Upload button, clicking Save instead doesn't work for me - I get a white screen, and upon clicking Back I get the edit form with a drupal_set_message STATUS with something like "For security reasons, your upload has been renamed to archive.tar_.gz.", and no files are listed in the Filefield widget. (tho the files were uploaded and listed in {files})

I also see this error written into a drupal_set_message ERROR within the filefield table div: "warning: unpack() [function.unpack]: Invalid format type p in /var/www/html/sites/all/modules/getid3/getid3/module.archive.tar.php on line 41."

Over the past months I had been testing with 400MB files that are dummy zero-filled, so I have little idea if this problem has been hanging around on my site. (BTW, often I see that if keepalive has timed out between the browser and apache then no progress bar is shown.)

EDIT:

I updated to getID3 1.7.9, and in the process I set the getID3 location path wrong -- FF couldn't find it and the HTTP 0 error went away. I fixed the path and the error's back. Disabling Filefield_meta completely eliminates this error for me, and looking in {filefiled_meta} is see columns named "audio_..." so I don't need this sub-module and having it disabled is fine for me.

With FF3.0.12 i can confirm that deactivating or uninstalling addons like greasemonkey or linkification solve the problem for me. I only use measureit, colorzilla and firebug now and theres no problem with uploads any more.

I can confirm that problem was in enabled FF module linkification.
After disabling the module, upload works.

For what it's worth, I also had this problem uploading with FireFox 3 - and my fix was to use FF extension NoScript to disable ALL javascript, do the upload - which then worked - then change the setting to ALLOW javascript, and save.

Someone mentioned using imagemagick instead of gd2 as a fix - but I was using imagemagick and still had the problem. So, it does seem to be a problem with multiple possible causes, not just one.

Confirmed!

For me it was the "smarterfox" addon. I disabled 'linkyfy tekst urls' and the problem went away.

My issue/fix may help those that had it working on a development server and then had these errors popup on a live server)

If you have CiviCRM installed check your CiviCRM Admin -Global Settings - Resource URLs
http://yourdomain.com/civicrm/admin/setting/url?reset=1

CiviCRM initially popluates these fields from the information in your civicrm.settings.php file, but DOES NOT update them later if you update civicrm.settings.php to reflect a new url.

Bad input in these fields will embed the civicrm jquery javascript from a "foreign" server on everypage regardless of theme and creates these errors because the jquery commands are not coming from a "local user" thus causing a user access problem.

Once I updated the CiviCRM resource urls to be correct domain, the problem disappeared for both Upload and FileField fields throwing the HTTP error 0.

Hope this helps.

Hey Guys-

An HTTP error 500 occurred.
/filefield/ahah/profile/field_content_image/0

I am having the same problem too. I am up to date with Filefield and ImageAPI. All but one of my content types allows me to upload into the field. All of my content types upload into field_content_image so I can make view call across all of my content. I have added another separate image field to the content type that is giving me problems and the other image field does not work as well. However every where else it works fine. I have checked the server memory and the permissions and all seem right. Any suggestions would be great!!.

Thanks-

Tony

subscribing

I also have this problem with OPERA 10
IE8 works ok

Same thing for me with FireFox. Disabling the Browser Highlighter Add-on fixed it! (why?, I have no idea).

Disabling browser hilighter fixed this for a support ticket we had as well.

Edit - Links to the addon

https://addons.mozilla.org/en-US/firefox/addon/11808
http://www.browserhighlighter.com/

Disabling Devel module worked for me on Firefox 3 on Mac.

Safari failed (no error but uploading never ends).

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

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

PECL not installed

Subscribing

# Same issue as k74

Subscribing.
Same problem in Firefox/Shiretoko 3.5 on Linux and Windows, Opera 10 on Linux, no problem in IE8 on Windows.
As a workaround I used NoScript (Firefox) to disable all Javascript, uploaded photo (that worked) then re-enabled Javascript.

I have not been able to identify any Firefox plugins as culpable, and that wouldn't explain the problem for Opera anyway.

However I was able to confirm that this only happened for a logged in user with admin rights (not THE admin user 1, but AN admin)
An anonymous user did not have the error.
I have not yet tested with a regular user, but I would have gotten complaints already from my users if they had this problem too.

Subscribing.
Same problem with Filefield 6.x-3.2 in Firefox 3.5.3 on Windows, no problem in IE8 on Windows.

Subscribing.
Same problem with Filefield 6.x-3.2 in Firefox 3.5.3 on OS X.

Subscribing.
Using Filefield 6.x-3.2, IE8, XAMPP 1.7.1 on Windows. This seems to be a file size issue -- in my case, no problem if size is less than 1MB, but always fails if larger than 1MB. I tried this systematically with varying file sizes, and I am convinced in my case there is somewhere a size limit of 1MB that messes things up. Checked phpinfo(), all relevant entries are set to 32M or 64M.

My problem was that any file over 1mb was not being uploaded. I just increased my upload limit size and it worked. Added upload_max_filesize = 10M and post_max_size = 20M to php.ini file on my Drupal root - as I don't have root access for this particular server.

I had issues with my /tmp folder having too many half uploaded files. I removed them and things are fine now.

I am having this problem not only when uploading, but also when attempting to remove files. I'm wondering if there is a bug in Drupal's ahah implementation.

According to Firebug, the post happens as it should; but, on the filefield.js side, $_POST is empty when the submission happens (at least on my server/setup). This is why upload fails.

I updated both Drupal core and Filefield at once just recently, so I can't say which would have been the problem. But, nothing in my server configuration changed, and it worked previously, so it's not the server.

I was indeed having a server config issue; my problem is different than above. Apologies.

Subscribing.

I was having the same http error 0 problem, using Firefox 3.5.5 and the most current stable FileField (6x-3.2).
I had FCKEditor installed.
I uninstalled it and installed WYSIWYG and Open WYSIWYG.
Still had the error.
I uninstalled all editors, but still had the problem.
I uninstalled all my Firerfox add-ons and it worked fine!
(at this point, no editors and no add-ons)
I reinstalled the Firefox add-ons one by one (now that's an exciting job!)
After each add-on was installed, it worked fine.
Then I reinstalled WYSIWYG and used NicEdit 0.9 as the editor.
It all works just fine, now.

From this, I assume that it was the editor(s) FCKEditor and/or OpenWYSIWYG. Even after I uninstalled them, I had problems until I uninstalled and reinstalled all the Firefox add-ons (I reinstalled every one of them).

Anyway, that's my story and I'm sticking to it!

My 2-yen...

I was running into this error using JUpload to load 20 images at a time. I binary-chopped the offending block of images and found the single image that was causing the problem (said "Deadly Jpeg", 1.5MB in size, available upon request for testing).

The Deadly JPEG also caused an error when an individual upload was used (ie: not using JUpload).

The solution (for me) was to increase the PHP memory_limit from 128M to 256M.

I'm running MAMP under MacOS 10.6, running FileField and ImageField 6.x.3-2, using Safari for the upload.

Version:6.x-3.1» 6.x-3.2
StatusFileSize
new534.3 KB

It is happening the same as in post #91. I am attaching the only file that produces "HTML error 0" to my website. I hope it may be helpful to developers.

Comment from #70 about getID3 / FileField Meta was the root cause in my case. Disabling FileField Meta before attempting to upload the file fixed the issue. Thanks!

#90 I tried your solution - no luck, nice story though.

#93 and #70 Thank you!!!!!!!!!!!!!! OMG that one was a sucky issue to solve. Thank you again!

Experiencing HTTP error 0 in a lot of different browsers (on Ubuntu and Mac OS X). No Filefield Meta, latest versions of modules. Memory limit 512 MB.

The HTTP error 0 has been occurring after I moved the site to another server (both Debian). I'll try to figure out what's the difference.

for me on os x error only occurs using Opera (10.10) but not Firefox 3.5 or Safari 4.03.

Status:Closed (fixed)» Active

Hello all,

Trying to make a long story short. After long debugging of the issue I reached the line that throws the exception inside the misc/jquery.form.js file. The line causing this mess is this:

doc = io.contentWindow ? io.contentWindow.document : io.contentDocument ? io.contentDocument : io.document;

The exception description, very surprisingly, is this:

Error: Permission denied for <http://channels.jdev.jeeran.local> to get property Window.document from <http://channels.jdev.jeeran.local>.

Surprisingly again, this error occurs on firefox 3+ and ie7+

So I have no idea where to go from here. Who exactly can I file a bug to regarding this? How can I debug this deeper? As far as I know, the iframe domain needs to be the same as the window that accesses it, currently, the iframe src is set to "about:blank" and this seems to be done intentionally in the jquery.form.js, the exception message states that both domains are the same so I have no idea where to go from here.

What properties are checked against each other for the domain name? I'm assuming window.document.location and iframe.src, but I'm not totally sure of this. I hope someone can help me a step further to fix this bug.

I am seeing this error with the latest filefield too.

I think this may be to do with server load.

I tried uploading a 1MB file, and got this error.
Shrunk the file down first to 1024x1024, ~300kb, and it uploads okay. So this may be that the server is getting a WSOD out of memory while trying to scale the file on the ajax call.

@mistnight, I think you are exactly correct in your assessment.

I have traced our HTTP Error 0 messages to exactly that same line of code in jquery.form, and we have the same error in references within the same domain:

Permission denied for <http://treet.tv> to get property Window.document from <http://treet.tv>.

While it surely appears this error is normal if there is a cross-domain scripting issue, in our case, there isn't, and like you I have tried my best to inspect virtually every document parameter for both the container, iframe, and referenced document.... I can see no discrepancies and document.domain is set to "treet.tv" in all cases.

I believe that solving this will eliminate a large number of these mysterious errors, but like you, I am having no luck determining why this error is occurring within the same domain. But, at least it smells like we're on the right track here.

(I am using the most recent jquery.form.js, v2.36, just to be sure, but have tried the default versions that come with Drupal as well as the ones that come with the jquery_update module. The error is solid and consistent in all cases, and it is the same line of code.)

I've actually found the problem. If you explicitly set the document domain for the parent container you need to explicitly set it for the child frame. That's the cause of this problem. If you remove the code that's setting the domain for the parent document weather custom script or some other module script this problem will disappear.

To test this out, you can add a javascript function inside the upload iframe that sets the domain of the iframe document to treet.tv and the call will succeed without any permission denied errors. But since this would be hacking the core, my advice is to find the culprit that's explicitly setting the document domain for the parent window.

Please do confirm weather this is in fact the issue and weather it solves it for you or not.

AA

@mistknight, that is exactly what I discovered on our site this morning! Because we are using lightbox-style modules (our own design) which have iframe references, I needed to set the document.domain to "treet.tv". My only guess is that setting document.domain explicity flags the domain as "tainted" (much as some languages like perl do when you 'touch' variables). I have to do some research to find out why.

What I ended up doing is the following:

if (arg(0) != 'node' || arg(2) != 'edit')
    drupal_add_js("document.domain = 'treet.tv';", 'inline', 'header');

This prevents the document.domain setting from taking place while edit forms are active, and for our site, it solved the problem totally, since the reasons the domain is set have to do with viewed pages only.

It seems very clear to me that this is the reason for many of the HTTP error messages. I ended out commenting out the try/catch code in jquery.form.js just to make sure the exception was raised, and tried it both the Firebug and Safari javascript debugger. When the document object was referenced, the error occurred immediately, and without the domain setting (as you discovered), it is working perfectly. This seems definitely one of the problems causing the error.

It is also notable that the "catch(e)" code is, for some reason, not passing on the exception. "e" is set to undefined, and probably is the reason why the error has been so obscurely reported.

Yep!

We were having weird issues with our site and discovered we were setting the document.domain in some of our custom code. Disabling our custom modules fixed our problem.

Thanks!

Glad someone found a solution. But could you please explain to us less tech-savvy what are we supposed to edit? Post no. 103 seems very helpful, but unfortunately I can't understand what files am I supposed to change.

Thanks in advance,
Jiri

@markus_cz: If you're not tech-savvy it may be hard to find. As far as I know, none of the standard modules set the document.domain, so if you are using all standard modules, then your problem may have a different cause than the one @misknight found in #102 above.

If you have any custom developed modules, or have made any changes to modules, I would contact the person who did it and point them to this thread, they would know if their module may be the cause.

Another thing you can try is to do a "View Source" on one of your pages and do a quick search to see if "document.domain" appears somewhere. It is possible that some module, even a standard one, may set it and may be contributing to the problem. But, we use over 80 modules on our site and none of them do, so you'd have to be using something out of the ordinary.

Subscribing
Content managers of a site I'm developing reported this same error 0 bug a couple of days ago. Apparently it is intermittent. The site has been up and running since dec 2009. I haven't had the chance as yet to investigate it.

Upping the php memory limit did the trick for me. I went from 128 to 256M, so don't assume you're ok having it at 128M already.

I was getting this problem. Solution was to disable the Devel module. Fixed it on FF 3.5.7 Mac OS 10.5.8.

Just encountered this problem on Google Chrome 4.0.249 Win XP SP3. IS working fine in Firefox 3.5.7 Win XP SP3. (Version 6.x-3.0).

Will report more later

Subscribing.

Content editors notified me of this error, although I was unable to reproduce it.

Hello, I had the same problem, http/0 error, additionally my swf upload field stuck too with bigger image files. Increasing memory limit in php.ini (xamp + win xp sp3) to 256M. The problem gone in firefox and chrome. Maybe problem is with GD2 library which I used.
BR

Subscribing. The same problem even with getid3 library installed (and with FileField meta on or off - the same result). Problem in Opera 10.10 and Win7. Devel disabled, PHP memory limit 256 MB. FileField 6.x-3.2. No wysiwyg, no custom modules.

For anyone who had the issue in #28, I was experiencing this and was pulling my hair out until I discovered that I'd accidentally added a blank like above the php opening tag in the template.php, which caused both the error in #28 (only in Safari; worked fine in Firefox) and which also broke our iTunes feed page, turning half of the HTML into escaped characters that of course didn't render...

Just a bit more feedback.
Updated to version 3.2 from 3.0. Still have this problem on the following browsers. (All on Win XP SP3)

Chrome 4.0.249
Opera 10.10

Works in
Firefox 3.6
IE8
IE7
Safari 4.0.4

Checked the theme template for blank lines none evident. Switched to Garland theme and problem persists.

EDIT: Tried it again in Chrome with Javascript turned off, the image uploaded fine.

Yes, IE works, chrome does not. I grepped through the files, but could not find any document.domain settings in enabled modules

Had the same problem on Drupal 6.15 and filefield 6.x-3.2. Tried all the suggestions above. None worked until I looked up " 413 Request Entity Too Large" error. Running Nginx 0.7.65.

Added the following lines in the server block of my config file

client_max_body_size 4M;
client_body_buffer_size 128k;

Found the solution at: http://forum.slicehost.com/comments.php?DiscussionID=1714

Same as redpuma, not working in Chrome. Works in FF.

same as redpuma @ #115 here, only with taxonomy autocomplete too

I got HTTP error 0 out of the blue when trying to upload to filefield. Everything was working, then suddenly it wasn't, without any changes. In all browsers, for all file sizes. Tried all the fixes mentioned, and nothing worked except downloading and installing the dev version of jQuery Update (jQuery 1.3) as per this post.

That was problematic though, as jQuery 1.3 seems to be incompatible with some things, including PECL uploadprogress bar. So I tried restoring an old db backup, and that did the trick. Something in the DB was causing this error for me. Not pecl, not php.ini, not apache, not my files directory, but something in the DB (something that was solved by jQuery 1.3 no less :O). Anyway, I after messing around for several hours I just decided to use the old db backup and go from there. Hopefully this error won't crop up again. Heck if I know what's causing it :O.

This error is caused by subdomain. if it works with www.domain.com and does not with domain.com or vice versa, edit your .httaccess file (uncomment and edit couple of lines).

In my case, the error is the same both with "www" and without it.

Thanks mansspams (#121), looking at your other posts, you are probably refering to http://webnewcastle.com/article/problems-http-0-ahah-errors-forms .

Playing around with base_url, which was set, did not solve the problem. I do however have some subdomain redirects etc. Temporarily disabling these redirects did not show any success though.

Subscribing

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

Just disabled Devel and still no joy (in Chrome).

Disabling DEVEL solved in Firefox 3.6, still problem in Opera 10.10.

So after I reloaded an old db backup everything worked fine for a while, but then the http error 0 returned when trying to upload to cck filefield, again out of the blue. Spent hours troubleshooting (tried EVERY fix I could find mentioned online), and eventually discovered that the error went away after I disabled and uninstalled the Advanced Poll module, of all things. Tried re-enabling it, and now everything's working honky-dory again. What the heck is up with this?

My situation:

New website with drupal 5 data migrated/imported into this fresh drupal 6. Everything was fine until the old products were imported into ubercart... not sure if this could be the cause? note that I get this error but the file WAS successfully uplaoded [when I check the folder on the FTP server]

What I have tried:

1. uncomment/add base_url to settings.php
2. changed to garland theme
3. turned off local javascript on my local browser [it then loads! but also weirdly outputs the array object to the top of the screen]
4. bumped memory to 256M in php.ini
5. checked htaccess for anything weird [its all standard]
6. tried with and w/o www. infront of my domain name
7. installed jquery-update
8. searched the source of the add-node page for document.domain
9. turned off devel module
10. permissions of files/ to 777

Any other suggestions? This is really crippling...

Thanks!

Try using another browser. It happend to me when using Iron SW (chrome), but get solved when using Firefox.

It's not solved, it means that the problem is only on Chrome.

Something about the return result must be bad for Chrome... Maybe the problem is not server side at all.

This might help you: Check your mod_security log (modsec_audit log). The "HTTP ERROR 0" was caused by an URL which triggered a block, in my case. Whitelisting the rule's ID solved the problem and everything works great again. Also, what's weird is that for one of my clients, even tho it's actually a 500 error (security violation), he got "error 0" on firefox/windows, while I received a 404 error on safari/mac. Pretty erratic behaviour.. This was driving me nutz. :-)

So, if you have access to the modsec_audit log file, make sure to check it for false positives at some point during your quest.

In short: filefield request -> modsec triggered error 500 -> 500-error page: file not found -> resulted in error 404 safari and "error 0" on firefox

I use the free set of modsec rules from gotroot.com.

@gentox:
the HTTP error 0 I am seeing in chrome is not related to a server error. The POST request shows up as 200 in the server logs, mod_security, in my case is not enabled.

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

Hi We're getting the error in firefox when users try to upload a photo..however, when we disable javascript, it uploads, but then we have to enable it again. Obviously we can't tell users that..Any help or suggestions on how to fix? Works fine in other browsers, IE and Safari.. Any help would be greatly appreciated.

Changing Browser solved my problem , deam i also tried every move.

Just wanted to add that I encountered this problem in Firefox, and disabling the linkification extension solved my problem.

Same error.
Multi-site installation, *only on IE* (8 and 7comp), permissions are fine (works ok with other browsers).

subscribing

subscribing

I don't know if this will help but I wanted to share my experience with this problem anyway. I have just started experiencing this issue after MANY months of problem free operation. We have a pretty fast connection here at work and uploads fast and without a problem on any account. When I'm at home on a slower connection it seems to "time out" and then gives the An HTTP error 0 occurred.
/filefield/ahah/story/field_original_video/0 error. I have set the following in my php.ini thinking that those times next to the memory_limit would do the trick and I still get the same results as above.

max_execution_time = 4000 ; Maximum execution time of each script, in seconds
max_input_time = 4000 ; Maximum amount of time each script may spend parsing request data
memory_limit = 256M ; Maximum amount of memory a script may consume (32MB)

My friend who is a developer said that my web host might have to restart their Apache server for these changes to take place. Any truth to that? He said that's what they do on the dev team here any time a php.ini file is changed because "Apache get's mad otherwise"

Another thought, does this have ANYTHING to do with clean urls or the htaccess file?

Just thought I might throw in my two cents. For the time being I had to email my client about how FTP works and how to paste code into their post and edit it....not nearly as glamorous or easy as before. :(

My friend who is a developer said that my web host might have to restart their Apache server for these changes to take place. Any truth to that?

This is true if it's the "real" php.ini file (usually at /etc/php.ini), but on a shared host you don't usually have access to that. Most changes to shared host php.ini files are immediate, but your host should provide you instructions specific to your situation. You can confirm that your settings are in place by visiting admin/reports/status/php on your Drupal site.

Version:6.x-3.7» 6.x-3.2
Assigned:Unassigned» lierrework
Issue tags:-ajax upload problem

for me, problem was solved by removing the vimeo module (http://drupal.org/project/vimeo).

The way I found it was by looking at the Apache error_log. Every now and then, I'd see:

PHP Fatal error:  Maximum execution time of 120 seconds exceeded in /var/www/vhosts/example.com/httpdocs/sites/all/modules/vimeo/vimeo.module on line 470

Just before the timeout for the imagefield. Not sure why they are related, other than perhaps JQuery_UI module?

After disabling the vimeo module, the problem went away. Re-enable the vimeo module and the problem returns.

Joe

Line 470 of vimeo.module is the closing bracket on this code snip:

<?php
function vimeo_download_thumbnail($id, $url) {
 
//Check if the containing folder exists -- if not, create it.
 
$dir = file_create_path() .'/vimeo-originals';
  if (!
file_check_directory($dir)){
   
mkdir($dir, 0775, true);
  } 
// <--- line 473
?>

So, the error has something to do with the file system functions in Drupal (eg file_create_path() and file_check_directory())?

Other error_log items I received while troubleshooting involve file.inc--as if the process got further along than the vimeo.module before it timed out at 120 secs:

[Fri Apr 16 17:38:33 2010] [error] [client 209.55.91.38] PHP Fatal error:  Maximum execution time of 120 seconds exceeded in /var/www/vhosts/example.com/httpdocs/includes/file.inc on line 116, referer: http://www.example.com/node/add/slideshow

and

[Fri Apr 16 20:25:40 2010] [error] [client 209.55.91.38] PHP Fatal error:  Maximum execution time of 120 seconds exceeded in /var/www/vhosts/example.com/httpdocs/includes/file.inc on line 102, referer: http://www.example.com/node/add/slideshow

And then I found this http://drupal.org/node/613918 about D7 and the functions file_create_path() and file_check_directory()

I figured out the cause of this http error 0 happening with the vimeo module. On my CCK node type, I had several fields available, and adding a vimeo video was optional. So, when you wanted to create a node without the vimeo field filled in, it still fired the vimeo module when either submitting the filefield for the imagecache image via the ahah widget or old style of submitting the node for publishing. With no vimeo content, Drupal got caught up in an endless loop of trying to create a blank filename for the vimeo thumbnail. It was a problem with the vimeo module, not filefield. A patch to the vimeo module available here fixes that problem. Details: http://drupal.org/node/730136

Moral of the saga is check the other content fields on the node you are also including filefield with the ahah widget and make sure they aren't interfering.

Joe

Same as @joachim, the error disappeared for me if I resized the (image) file manually first. It's a CCK file field.

Assigned:lierrework» mammasan

HI Genox,

I don't have a mod_security log, but upon checking my server error.log I saw this which corresponds to the Error 0

ModSecurity: [file "/etc/httpd/modsecurity.d/05_asl_scanner.conf"] [line "37"] [id "351000"] [rev "1"] [msg "Malicious File upload attempt"] [severity "CRITICAL"] Access denied with code 403 (phase 2). File "/tmp/20100423-073457-XXX@XXX-file-6dLpmL" rejected by the approver script "/usr/bin/modsec-clamscan.pl": 0 Unable to parse clamscan output [WARNING: Can't connect to clamd.] [hostname "www.website.co.uk"] [uri "/filefield/ahah/profile/field_cab_picture_1/0"] [unique_id "XXX"]

Which seems to be what you are describing in your post.

Can you just confirm that this is case and if white listing the ID would solve the issue

Hi mammasan,

Yes, this might be the problem in your case. So far, the filefields triggered two rules on my server, resulting in access denied/not found errors and the famous "error 0" on some plattforms/browsers:

a) one rule was triggered due to the composition of the URL (string matching) generated to POST data: Whitelisting solved that.
b) another rule was triggered due to failed scan attempts by clamd-scanner on upload: This can be either solved by whitelisting the rule or disabling clamd scanning on upload alltogether. I chose the later.

Note that whitelisting the rule will disable scanning of uploaded files anyways, afaik. So you might aswell disable all clamd-rules and make it run as a CRON job on a daily basis, scanning user directories during low-traffic hours, if you have lots of users uploading files or public community sites.

Thanks for that, hopefully at least this will narrow down snagging if not fix for good! (oddly though this has only started happening a few days ago and I know I haven't changed any settings eithe ron the server or drupal itself.

I've had to open a request with my host as I tried adding a rule to the .htaccess but that had no effect.

The amount of uploading isn't that great as we only upload a few images a week to user accounts.

Disabling Source Domain worked for me, fwiw.

I ran in to this problem today and after experimenting some I found that even though I set no limit for dimensions (or a higher dimension) the server will give the 'HTTP error 0' response for an image that is 1742x2386 pixels while accepting an image that is 1741x2385. From some Googling i concluded that this might be because a larger dimension might require too much memory from the server, and thus I tried changing the memory limit in .htaccess (if you have permission to set it there, otherwise it's set in php.ini if I recall correctly) and that solved the problem so that also the original image with dimensions 2544x3485 is accepted.

So in .htaccess, look for;

# Increase php memory limit
php_value memory_limit 32M

32M was original setting for me, changed to 64M the problem was solved as far as I can tell.

The problem with "error 0" in general is that it is only a symptom, so to speak. From my experience, "error 0" can result from either "Access denied", "Script error", "File not found" and a number of other causes. These errors happen earlier during execution of the script or even early on by Apache trying to serve the page. Thus it is impossible to narrow it down to one single problem.

One possible way would be to create a checklist for Drupal Admins to go through when encountering "error 0" on their client's browsers. There's no way one single solution applies to all occurences of "error 0".

For example, haveing not enough memory dedicated to PHP (memory_limit) results in a PHP error, thus an error code, thus "error 0" in some (not all!) browsers. Also, a triggered mod_sec rule ends up in an "Access denied" error, again showing "error 0" in the client's browser.

I'm not sure about that, but maybe it has to do with the way some Javascript libraries handle error codes and maybe a lack of error handling at this point - because the only thing which all occurences have in common is the usage of AHAH forms to upload files or make changes via ajax. The lack of interpreting errors causes the dialog boxes simply to show "error 0" which might be aswell called "oops, something went wrong.." leaving it up to you to browse thru log files and do all sorts of trial and error. :-)

I just developed this bug. Everything was working fine, and then I got the dreaded http 0 error. This, without any changes to my website.

I solved the problem by using the throbber, and not the upload bar.

This is a bug. Sorry, it's not a configuration problem. If the primary developer of this module doesn't want to address it, that is fine, I have bugs that I simply throw my hands up and say, I CANT FIX IT. However, the issue needs to remain open SO MAYBE someone else can fix it. To close, it and bury it, just guarantees it will never go away.

Use the throbber, it fixed my problem.

If anyone can contribute any patches that make any improvements to prevent this problem, I'm more than happy to review them. Please file new issues as they arise however, since (as people have noted repeatedly) there are variety of sources related to this problem. The fact remains however, so far in this issue every single problem has been caused (and eventually solved) because of a server configuration problems.

What about the upload bug that only occurs in Chrome but not Firefox?

IMO that's something to do with code.

I am having the same problem with uplading or removing images from a filefield and gettin the http error 0. I have the same problem and I narrowed it down to a starnge occurrence:

When I upload an image with or without text in the body, the upload / download works. If I copy the text from another site, and paste it, then it sometimes breaks filefiled and the save function, and gives me this error.

Some snippets that I cut and paste work, others break the add form. The snipppet I am pasting is for a hotel and for some reason something in the text in the body is breaking the submit form and filefield and giving this error.

Any ideas?

Ditto

subscribing

subscribing, I have this error only with Google Chrome

Nearly lost my dignity this morning dealing with this issue.
Just found a solution. What I did was went through every file in which upload settings can be defined, ie: settings.php, php.ini, .htaccess and ensured that each was set the same: 64M in my case. Voila! I think the crux was the .htaccess (which escaped me on first pass as it was hidden). This was after hours of disabling/uninstalling/reinstalling all Filefield dependent modules and Firefox add-ons.
Here: http://drupal.org/node/207036
And here: http://drupal.org/node/76156

still have this issue after upping mem limit in php5.ini , .htaccess and settings.php to 96M
subscribing

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.

Essentially what you've done is disable the JavaScript based uploading, it shouldn't cause any harm other than the AJAX uploader will no longer work.

After a lot of experimenting, the following hack worked perfect for me:

change in filefield.module line 478:

function filefield_edit_access($field_name) {
  if (!content_access('edit', content_fields($field_name))) {
    return FALSE;
  }
  // No content permissions to check, so let's fall back to a more general permission.
  return user_access('access content');
}

to

function filefield_edit_access($field_name) {
  return TRUE;
}

In addition to my earlier comment...

I'm on a Godaddy shared hosting server (yeah yeah I know, I'm essentially just there for the domains :p).
When you setup a Godaddy server, you get to choose which OS you want. Windows or Linux. (defaults to Windows)

You can later always switch back through the Domain Manager.

In my case, switching the Linux for a Windows based setup cleared the above mentioned problem with the "ahah" wrapper.
So my filefield module needs no hacks anymore and just works perfectly.

I found out what happened in my specific case:
- the filefield module version 3.3 checks now since this release exclusive for 'access content' permissions, I gave my client permission to 'administer nodes', but not for specific for 'node access'.
Administer nodes gives normally permission to access content, but not in this particular case. normally people who have rights to administer nodes have also access content rights:
see
* In determining access rights for a node, node_access() first checks
* whether the user has the "administer nodes" permission. Such users have
* unrestricted access to all nodes. Then the node module's hook_access()
* is called, and a TRUE or FALSE return value will grant or deny access.
(node.module)

hanno, that's the first theory i've seen in this thread that makes any sense. if you grant them access content permissions does it resolve the issue?

Version:6.x-3.2» 6.x-3.3
Assigned:mammasan» Unassigned

I was having an issue where some MOV files would upload fine and some would give me this HTTP error 0 message. (6.x.3.3)

@drewish Yes this is definitely a bug. After I granted access to 'access nodes' besides 'administer nodes' to the webeditors, it all worked fine. I posted a patch in #696906: filefield_edit_access() and filefield_view_access() should use content_access() instead of checking content_permissions specific where this bug was introduced.

@Hanno, @drewish: sorry I am not sure if I understand it right. I have this problem (error) even if logged in as user 1. So could it be permissions-related?

@my-family When you as user 1 has problems as well, it is not permission related. User 1 always get user_access (function user_access always returns TRUE if uid==1). As far as I can see it may as well caused to javascript, directory-permissions, or php uploadlimits.

Subscribe

Least anyone think this problem is mystical, it's also present on d.o itself.

Try to upload something with chrome into the comment attachment.

subscribe

subscribe

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.

"For what it's worth, I also had this problem uploading with FireFox 3 - and my fix was to use FF extension NoScript to disable ALL javascript, do the upload - which then worked - then change the setting to ALLOW javascript, and save."

This solution completely worked for me.. I'm experiencing this with the comments upload module. Everything works fine, looks like it is uploading however I get the error when I click the attach button. I turned on Noscript and blocked everything and it works like a charm, file is attached and I can attach another.. So I suppose now I'm going to go through all of the scripts that are loaded on that page one by one and figure out where the culprit is.. Let the fun begin

So as suspected jquery ended up being the culprit here. I had to downgrade jquery.js to 1.2 to have things finally work.

Blogged about it and posted the long version here:
http://blog.netflowdevelopments.com/2010/07/01/me-myself-and-drupal-chap...

I've build my site on localhost (WAMP) without any issues. Once moved to live server (hosting) HTTP error 0 came up for every file/image upload. If this is so common isuue should it be treated by drupal's crew as critical?

I'm using 6.3.3 and have exactly the same problem. for one site, I did what's said in #165 and it worked. for another site, I did the same but not vail.

ok. I confirm that my problem can be fixed by replacing /misc/jquery.form.js with the more recent release at http://github.com/malsup/form/raw/master/jquery.form.js?v2.43

#182 did not solve the problem for me. (yes, I made sure that caches are cleared and the updated library is loaded)

In the end I had to get rid of jquery.form.js entirely. It removes some pretty eye candy and functionality here and there from drupal but the ability to attach files to comments outweighed that. Would sure be nice to have both though

Change the browser, I wasted my 40 hours solving this weird thing. But as soon as I changed FF to IE, it's working fine!!

It looks like its not an issue with the module itself. The upload button triggers the upload process via ajax/ jquery. It expects json formatted data from the server when the upload is complete. If the data returned is not in proper json format, the ajax/jquery process that handles the returned data breaks and causes the error you see. For example, I had the memcache admin module enabled, which outputs data on hook_init(). When the upload process finished on the server side, the filefield callback would spit out its json data, the memcache admin module would also spit out its data on this request as well. The ajax/jquery callback function would receive the json data plus the memcache output, which naturally is not proper json. So if another module is outputting data (like on hook_init()) then you will experience this error.

my two cents.

@magicRoot I do believe that's it. 0.o

Any solutions though?

The quickest fix would be to add hack into the javascript and output the data that is being returned by the server. Then you can disable whatever output that is if its not crucial, or write the output to log file in the server before sending it to the browser. I say the quickest because apart from the json being output, any other script executed in the control flow of the drupal bootstrap sequence can output something; it would be difficult to trace that.

Another solution (one which i will look into further, and perhaps make it scalable to all ajax calls) would be to sanitize the data being sent from the server to the ajax callback function in the browser somehow; that way, you filter out only the data that was intended to be sent.

A third solution would be to override the upload request to call the function that deals with the upload directly, instead of going through the drupal menu routing system, so that only that function executes, but that can get tricky too.

your thoughts?

I was having this problem in Chrome 5 only (all other browsers were fine, but Chrome is now my browser of choice).

After reading the suggested solutions here and trying a few of them (mostly without success - the filefield_widget.inc hack worked but seemed a bit extreme) I turned my attention to the browser itself.

I isolated the problem to the SmoothScroll extension. Once that was disabled the problem went away. Strange but true.

I have the same problem with Chrome 5.x and also have smothscrolling extension installed. I confirm that disabling that extension the problem is solved.

subscribe

subscribing, I have this error only with Google Chrome without SmoothScroll extension installed.

I have the same problem with IE and Firefox. Tried many things #182 #184 did not work for me

I have drupal 6.17

This issue has been going on for over a year. Nobody seems to have the magic fix. It is due to module configuration. Some modules are breaking it but I don't know which ones. I know this is true because it works for me on some of my sites and is broken on others. EVERYTHING is the same except different modules in the mix. It would be a real pain, but you COULD solve this problem by disabling every module and then verifying that upload works and then start enabling modules one at a time until you find the culprit. Maybe we should all throw a small donation into a pool for somebody who can actually sit down and go through such a painstaking and time consuming process. But module conflicts are the problem... unless somebody here can confirm they had the problem on a fresh install. Cheers, K

Hello all,
my two cents.

I tried a lot of things and nothing worked. I exported and re-imported my website from the sandbox where i did not have any errors.
Well, the error was there after the import.

On the production site I was on the linux free hosting from godaddy. On the sandbox I was on the Linux delux ( the cheapest one...).

I paid to move the production from the free hosting to the linux delux ....... and Voila' it works perfectly.

I had problems with all the AJAX call, the update.php and this http error 0..... Everything went away.... Paying godaddy... sad sad story
good luck!

Version:6.x-3.3» 6.x-3.7

Same problem on FF (3.6.6), IE8, and Chrome (5.0.375.99). Only happens when file sizes are somewhere > 1.25 MB. Error message is:

An HTTP error 0 occurred.
/filefield/ahah/gallery_image/field_gallery_image/0

My php.ini (shared hosting):

post_max_size = 100M
upload_max_filesize = 10M
memory_limit = 32M

I increased memory all the way up to 512 MB to no avail.

I don't have most of the conflicting modules listed above. Disabling WYSIWYG did not help. Some of the other things listed here are over my head.

But, I notice that the Image upload box says that my max filesize is 2MB, which is incorrect. (http://drupal.org/node/863932)

You're probably being forced to a limit of 2MB by your host. If it says 2MB, it's really 2MB. See the handbook page on increasing max file size.

@197 - I checked with my host and also phpinfo(). Also, admin/settings/uploads says it is 10MB, not 2MB.

OK - the HTTP error 0 is gone now, but the fileupload box still says 2MB. I have changed the max file sizes in both php.ini and settings.php. Now, I just get a normal error/warning in Drupal if the file I try to upload is > 2MB.

Update: This was not at all obvious to a newbie like me, but I needed to go to admin/content/node-type/, and manage the fields of the type of filefield I was trying to use (in this case, it was gallery-image from the Views Gallery module). There is a file size max there that I increased to 10MB, and now the filefield shows this and I can upload files >2MB.

I also was experiencing this problem and wanted to add some weight to #186. The problem in my case was that I had memcache output enabled, which was in fact dumping extra 'stuff' (non-json) into the output. When I disabled this, all was well. I'm guessing others that are experiencing this problem do have one or more modules adding 'stuff' to the return data stream that shouldn't be there. Interestingly, I also have devel enabled, which outputs statistics at the bottom of every page - and this is NOT causing a problem. I presume this is because it is a bit smarter about determining when (or where) to add the stats.

One quick addition to the solutions. If you are using the SecurePages module, you need to visit /admin/build/securepages and add an Ignore page for the paths:

filefield/progress/*
filefield/ahah/*

Otherwise, if you try to upload on an HTTPS page, SecurePages will try to redirect you to the non-HTTPS version of the Javascript and thus break the javascript call with an error 0. The ignore setting allows that script path to be returned in either HTTP or HTTPS depending on what the page calls for.

Well in my case my problem where in www. , when i used the site with www prefix i got the error , when i use it without www everything work fine !

Thanks to #200.

I had in /admin/settings/memcache

"Show memcache statistics at the bottom of each page" checked

Unchecked and it works, no more error 0

Seems like this issue has been open forever in the Memcache queue: #319697: file uploads file when memcache statistics are written to page footer - easy fix.

We've recently run into the HTTP error 0 issue like everyone else on this thread, but narrowed it down to a problem somehow related to Organic Groups. When using Organic groups, users get assigned a role but only within the context of the group. So group users don't have site-wide permissions, just within the group. This appears to cause a problem with the AHAH javascript when using the Upload button. A user without site-wide edit access to the file field in question is thrown the HTTP error 0 when pressing the Upload button, but can successfully submit the whole edit form using the Preview or Save buttons. A user WITH site-wide edit access to the file field in question does NOT get the error.

When I give the "Authenticated User" role site-wide edit access to the file field in question the AHAH error goes away for all users. So there seems to be some disconnect with the permission checking within the group context.

I think it might be related to the permission checks discussed in #696906 Anyone else having this issue when using Organic Groups?

Thanks,
-Tim

I'm getting this error now on a site that was recently migrated to a LiquidWeb cloud server. Prior to migration (old host was RealityCheckNetworks) there was no problem. Filefield version 6.x-3.1. I notice that only one content type has this problem; while the same exact filefield works fine in other content types! I do not have memcache or devel installed, and the file is smaller than all my stated limits. I am not using any node access modules. This is hairy.

HI All,
just to add my little bit, i had this issue also, managed to narrow it down to the multistep module, the file upload never worked properly if the file upload was on the first page.

I applied the multistep patch and got some functionality, the strange thing is that image upload works flawlessly, but just not file upload, even though the images are larger than the files uploaded.

occasionally i could get the file upload to work but it really depended what mood drupal was in.

just find it strange that it has no problems uploading an image, processing it and returning an image thumbnail but a simple small file upload cracks it.

thinking it could be a mime issue, but that is just a guess.

just thought id share my experiences, almost half tempted to start creating a file upload widget from scratch so i know whats going on, but when this module works it works well,Kudos to the developers

Increasing the PHP memory limit to 256 MB fixed it for me.

After I disabled JavaScript in my browser, I tried the upload again and got the following error:

Fatal error: Allowed memory size of 201326592 bytes exhausted (tried to allocate 20400 bytes) in /home/archstl/public_html/sites/all/modules/imageapi/imageapi_gd.module on line 44

It would be awesome if ImageField/FileField could show this error instead of 'error 0' when memory is exhausted (if that's possible), since this is probably the issue or 90% of those getting the 'error 0'.

For me, I could see the file uploaded to the server, and the upload form sat for a bit, but it finally filled up the memory for the process (since the image was about 1 MB), and then I got the error. More details about my experience with the dreaded 'HTTP error 0,' and my long process for fixing it.

Just giving props to Post #163 by sunchaser , commenting out this section of code did the job.

in file filefield_widget.inc
Inside function filefield_widget_process($element, $edit, &$form_state, $form) {

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

Dirty hacks FTW!

Since "error 0" can have so many reasons, I'd suggest implementing a proper error handling on the JS side of things to narrow down all those individual problems. Since it can be everything from PHP to mod_security, it's impossible to tackle every error here. Yet it is extremely time consuming to troubleshoot something with as many possible reasons like our beloved "error 0".

Where is the right place to request such thing?

battling with this all night. got the issue on 2 different servers (trying same 2M image file). then actually tested on my local on was getting the issue there as well.

local mem limit was set to 160M. Boosted to 300M and still the HTTP 0 error, Then i did the node submit without first uploading and i could see error reported in #208 (except at 300M). Boosted memory to 600M and file uploads fine.

but seriously.. 600M for a 2M image.. but this was interesting:

the test image was 1.99M but it was also 6144x4096 and the imagefield was set to 6000x4000 as its max resolution - but MAX doesn't really mean it won't allow something larger it means:

"The maximum allowed image size expressed as WIDTHxHEIGHT (e.g. 640x480). Set to 0 for no restriction. If a larger image is uploaded, it will be resized to reflect the given width and height. Resizing images on upload will cause the loss of EXIF data in the image."

i modified the image size to 4000x2667 (which actually boost the file size to almost 4M) and the image loads quickly.

i also tried setting imagefield's max res to 0 (unlimited) but this still causes the error with the higher res image.. then.. and this was surprising.. i set the fields max res to 8000x6000 and now the high res image loads fine.

so what did i learn:

- GD takes a stupid amount of memory to scale down high res images
- there is a bug in latest imagefield as 0 != unlimited

hope this helps someone.. been at this for a few hours now.

@liquidcms: Compressed images have to be uncompressed to memory to be resized and GDlib internally uses 40bit color depth which means: A lot of memory is being used, just to resize an image. It doesn't matter how big the file size of a JPEG image is, as the memory consumption is not based on the compression factor but on dimensions and color depth.

Use ImageMagick to handle images with large resolutions if your hosting environment supports it.

it happens when content type name is too long
had this error when used 'advertisement' as content type name
checked twice

worked when changed to 'adv'

image fields have this error in many differents contexts: i have it on an default openatrium installation, then on my drupal 6 playground and finally also on my drupal 7 site :)

seems like that is THE error in drupal. omg.

edit: haha, an firefox add-on was the issue. at least in one of those mentioned cases.

I had the issue just on Firefox (not on Opera, not on IE) and the reason was the add-on called "Inline Translator" (https://addons.mozilla.org/de/firefox/addon/9842/)

Deactivating that add-on made the error disappear.

I had this problem with Chrome but not FF or IE.

The solution turns out to be to install a more recent version of jQuery Form, but not the most recent (2.16 not 2.46!) because it needs to be compatible with the version of jQuery that I am running - jQuery 1.2. This was within the patch at http://drupal.org/project/jquery_form_update

If I used 2.46 (from http://jquery.malsup.com/form) I got the "http error 0" dialog on all browsers.

Sean

This fixed it for me

Adding the following to you htacces file

php_value post_max_size 5M
php_value upload_max_filesize 5M

Good luck everyone.

The problem for me is with memcache api enabled
I desactive it and I don't have any problems
but it's a problem because memcache or other cache modules are very important too
I will investigate on memcache issue
this issue don't resolve the problem for me
http://drupal.org/node/319697

Add my comment to the "same error for me" group.

But, I am logged in as the admin user, don't have memcache installed, have modified the .htaccess and php.ini files has suggested above. Did not have the problem prior to moving to 6.x-3.7.

Maybe there are just too many variables that could cause the HTTP Error 0 issue. I notice that I a similar error (HTTP Error 403- /filefield/ahah/[content_type]/field_[field_name]/0) when attempting to remove a file from a current node - which was created prior to moving to 6.x-3.7.

Not sure if my $0.02 helps or adds to the complexity.

The suggestion in #201 just fixed this error for me. I was seeing it for fileuploads, and adding those paths to SecurePages ignore section made the error go away.

what worked for me: I was attempting to upload an image that was too big... Once I shrunk and compressed it, all was well.

I had the same symptoms and initially turning to the throbber worked for me. Then I discovered I didn't have correct permissions on the upload directory (after transferring site to another server). Once I set these, I could turn the upload indicator back on and it worked fine.

I'm Acquia drupal commons by the way.

Hope this helps someone.

Hi Sentinelcz,
How did you go about enabling PECL Upload progress?
Is it relatively easy and did it definitely resolve the issue?
Thanks

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.

Version:6.x-3.2» 6.x-3.7
Assigned:lierrework» Unassigned
Issue tags:+ajax upload problem
StatusFileSize
new12 KB

Hi qinwubi
I tried upgrading the jquery.form.js - to Version: 2.52 (07-DEC-2010)

$ cd /drupal/misc
$ mv jquery.form.js jquery.form.js_BAKUP
$ wget --no-check-certificate http://github.com/malsup/form/raw/master/jquery.form.js

The problem persists after running cron and testing in a fresh browser.
What else did you do to get it working?

seanwallis: where did you source the correct version of jq.form from?

Thanks.

Priority:Normal» Major

FileField [filefield-6.x-3.9], ImageField [imagefield-6.x-3.9]

I'm having the same issue. But only with a few files.

Do I need to use the patch with filefield-6.x-3.9 to fix the problem?

Thanks,
Marco

So has this issue been fixed in version 3.9? I am having the same issue with ImageField and FileField 3.7.

An HTTP error 403 occurred.
/drupal/filefield/ahah/items/field_image_cache/0

Thanks

Category:bug» support
Priority:Major» Normal

@Stomper: No. Per the 200 responses above, this is not a bug in FileField or ImageField. It is ALWAYS a problem caused by another module or server configuration. Upgrading probably won't help the problem.

Title:HTTP error 0Solved for my Case

I was getting this error only on image uploads, the system was working as expected on file uploads. Following hours of reading and testing, I realized I had a version of imagefield that wasn't working with the version of filefield I was using. After updating my imagefiled module to the correct version, everything worked fine.

Title:Solved for my CaseHTTP error 0

@oskarblue: Remember that the "Issue title" and other fields on the comment form change details of the entire issue. :)

Title:HTTP error 0HTTP error 0 - Update to 3.9 helped

I just went through updating my modules including FileField and ImageField. I upgraded them from 6x.3.7 to the current latest 6x.3.9 and it seemed to fix the issue. I no longer get the error message and I can upload images using ImageField. I have yet to try FileField though. I did not have to do any configs with my server/localhost.

For others experiencing the same issues as discussed originally and are not running the latest version, perhaps try updating to the latest version. Make a backup first for good measure.

Title:HTTP error 0 - Update to 3.9 helpedHTTP error 0

Sorry all, I changed the issue title with my previous post. This post was intended to return it to the original issue title.

unable to upgrade filefield 3.7 to 3.9.

unable to upgrade version.

Version:6.x-3.7» 6.x-3.9

Getting this error (only sometimes...) using Chrome 8, not getting the error in Firefox.

Not using any upload progress indicator, using a Filefield, and upgrading from 3.7 to 3.9 did not fix the problem.

If you're getting the problem only in 1 browser, check ur extensions.

I'm running into this problem as well. Most of my site's users haven't encountered the problem.

Here's the strange part though. Two users have repeatedly encountered this problem. They continue to get the problem when they try different browsers.

This is a headache of a problem because it can be caused by so many different things. I think I've figured out what's causing it for me though.

I disabled CKeditor and the problem seems to have gone away for the affected users. Other people have had this issue with FCkeditor so I'm guessing there's some sort of conflict between text editors and a filefield on the same "add node" page.

This is not a solution for me since I need both a filefield and a text editor on the same add node page but it is a relief that I believe I isolated the problem. I'm going to try some other text editors.

It is a conflict with another module for sure. But it's doubtful that CKeditor is the culprit. I am running CKeditor on all of my sites and only one is having this problem. The only way to troubleshoot the problem would be to disable one module at a time until you find the suspect. Thankfully, my site is personal and I don't need this functionality for users. Whenever I need to upload an image I simply disable javascript from my browser settings and the image uploads fine. But I can see why this is not a solution for community sites.

Yep, that's what I did. Disable a module at a time. After disabling Ckeditor, the problem went away. Fingers crossed that this will keep this error at bay.

Obviously CKeditor and Filefield don't create a conflict for all users on all sites. Most of my users weren't encountering this problem and I've used the combination successfully on other sites.

However, for some reason the combination of these two modules and a certain third factor, which I can't identify, were apparently causing the problem for certain users on one of my sites.

I'll try to post any more information I gather.

Got this problem on multisiting too. Found one thing:

When I'm tryin to upload width FileField / IMCE in main site (domain name same with drupal's folder name) - it's ok. When in other multisiting's sites - it does not works.

And files does not uploads even when I'm trying to upload from my main site installation but from another domain (sinonim).

How can domain name affect file uploading process?

Interesting, mine is also a multi-site install. Getting rid of CKeditor did the trick for me though. Went to BUeditor and haven't seen the issue in over a week.

Title:HTTP error 0 Solution php memory and execution time: HTTP error 0
Issue tags:+ahah, +php.ini, +file size limits, +php memory

What worked for me was increasing not only the php memory limits but it's execution time. I noticed this was the solution when small images would upload but not the large ones. If this is the case, look into increasing these limits using .htaccess, php.ini or the drupal tweaks module.

I hope that helps!

Title:Solution php memory and execution time: HTTP error 0 HTTP error 0

That doesn't fix the issue for me. I tried changing my php.ini values, restarted apache and still get the error. In fact it happens sometimes within 10-20 seconds of starting my upload, other times after around 10 minutes of uploading. And then sometimes I can get files uploaded without the error at all.

max_execution_time = 1200 ; Maximum execution time of each script, in seconds
max_input_time = 1200 ; Maximum amount of time each script may spend parsing request data
;max_input_nesting_level = 64 ; Maximum input variable nesting level
memory_limit = 384M ; Maximum amount of memory a script may consume (16MB)

Changing topic back because it's not "the solution" at least for everyone.

I spoke too soon. This problem has reared its ugly head again on my site even after the switch from CKeditor to BUeditor. I've tweaked the PHP.ini limits, upgraded modules, disabled supposedly problematic modules, and am still getting this issue.

The difficult part about this is that I can't recreate the issue. Only certain users are experiencing it and as far as I can tell it doesn't have anything to do with the browser they are using.

I'm going to attempt this next:

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

Commenting out the code suggested by #163 did not work either. If anybody could please offer suggestions, it would be greatly appreciated. I'm trying to troubleshoot this on an active live news site and this has grounded our writers.

Here's a summary. For 9/10th of my users, there is no problem adding content. For 1/10th, they are able to post OK at first, then they get this error. Oddly, if I ask them to post a new post with no image, they still get this error. Even more oddly, if I ask them to send me the original post and picture they attempted to post and I post it, I don't get the error.

In other words, whatever I do I can't recreate the error. However, users that do encounter the error once can't avoid it again. This happens even if they switch browsers.

I thought I had tracked the problem down to CKeditor. Disabling this module eliminated the error for some users. However, now other users are getting the error.

If anybody could help me through this problem, you would be a true savior. I'm close to getting rid of Filefield on the site but we already have about 75 posts using Filefield so I would rather not. Thanks so much. I know there are people much smarter than me on these matters on this site so I would greatly appreciate the help.

sockah,
Like everyone else here, we've had this problem crop up previously (see post #205 above). For some reason, giving the "authenticated user" role edit permission on the filefield in question (in addition to their normal role and the other permissions required to add nodes) fixed the problem for us. I think our problem might have been limited to Organic Group users, but I'm not 100% certain of that anymore. It's worth a try if you haven't already done this.

-Tim

Thanks Timwood! I'm not using Organic Groups but am willing to give anything a shot. How do I give authenticated users permission to edit the filefield in question? When I go to mysite.com/admin/user/permissions, I don't see any permissions relating to filefields.

Many thanks.

Sorry, we use a lot of modules and sometimes I forget what modules add which feature. You will need to enable the CCK sub-module "content_permissions" to enable field level permissions. Or use the drop-in replacement module Field Permissions. I'm currently using content_permissions in our Drupal 6 sites. But, if you aren't using this module already maybe it's not an issue/fix/option to your distinct HTTP error 0.

Ah thanks much Timwood. I'm guessing that isn't the problem/solution for me since I'm not using either of those modules.

What's the proper way to debug an issue like this? I tail'd my apache error logs and nothing happens when this error occurs. Also nothing in the dblog. Do we need to enable PHP error logging in php.ini to see an error about this? Where's the sysadmins at.. Any idea where an error like this might be logged?

Also I can vouch for this issue happening to me across all my browsers now, IE, FF and Chrome.

Also, it happened to me once on a taxonomy autocomplete lookup!!! That was kinda funny.

What's the proper way to debug an issue like this?

- Turn on PHP display_errors in your php.ini file.
- Install Firebug or use Safari's debug mode, or similar for your preferred browser.
- Using Firebug, use the "Net" tab to inspect the return values back from the server during the POST AJAX request. The URL should be similar to http://example.com/filefield/ahah/[type-name]/[field-name]/[delta]. Make sure you're getting a valid JSON string back without extra junk added by some other module like devel or memcache_admin. If you're getting a PHP error during the AJAX request, work to solve the particular error that is returned.

I remind that "HTTP error 0" is not a report of the actual problem. The real problem may be different, but it's impossible to tell what exactly.

This issue:
#646694: AJAX: Terrible reporting of status 0 response from AJAX request ("HTTP Error 0 has occurred")
is aimed at converting "HTTP Error 0" to a factful report which actually tells you what's wrong.

Quicksketch, do you have any suggestions how to debug if I personally can't recreate the error? I will try to walk one of the users getting the error through this process but I fear it will be too complicated. Thanks.

And to anybody who is still listening :), does the below shed any light on my problem? This is what appears when the ahah error happens:

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

And I have ruled out that the file size is too large. This error is occurring with relatively small files. Thanks again.

Sockah: You might want to setup a screen on your box and tail | grep your php error logs to a file as Quicksketch so kindly helped us out with above.

If this is confusing, basically you're setting up another log file by watching your php error log for instances of "whatever" (by using grep) and saving only those lines separately, so you can refer to them a day later after the error has happened to one of your users while you weren't watching. That way you don't have to go through your logs with a finetoothed comb. Similarly, you could grep your current error logs for possible error strings.

I'll follow Quicksketch's suggestions and see if I can come up with something useful that might help someone else (and meee!)

For the record, I don't use memcache admin or devel, however I do use:

Performance Logging 6.x-1.22 <-- which may be part of devel, and may be causing an issue perhaps.

Thanks Parasox. I appreciate the reply. I would like to make sure I understand one thing.

When you talk about the error logs, are you referring to the Drupal logs accessible at mysite.com/admin/reports/*, the Apache server logs, or some other log I'm not even aware of?

The logs that Quicksketch referred to above. You need to turn on php error logging in your PHP.ini file, in your case to a file because you can't reproduce the error, so displaying it isn't going to help you.

In my php.ini I see that as log_errors = On

And error_log = filename

or

error_log = syslog if you'd rather them go to syslog (in my case, that's /var/log/syslog)

Then as I posted above, you can use tail piped through grep so you can "watch" for a string and log that to a separate file if your syslog or custom php error log that you define moves quickly.

Thanks Parasox, I understand now. Fortunately, log_errors was already turned on. I'm going to start working through it for clues.

FYI I've put in a feature request with SecurePages to include the FileField paths by default: #1035670

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

Nobody should close this bug just because they set their base url wrong. If you happen to have your base url set wrong, fix that by all means. If that solves your AHAH problem, great. But a glance through this thread clearly indicates that the HTTP error 0 message can be caused (and fixed) by a wide variety of conditions, and the base url is usually not involved. It's just something to check IF the error occurs for you every single time. If your error 0 message is intermittent (as it is for many people), you can obviously ignore base url as a possible cause.

This is a javascript error. And nobody really knows what exactly is causing it. If you turn off your browser's javascript you will be able to upload an image. This error is the result of a conflict with another module (which one(s) is anybody's guess). Nonetheless, this issue has been going on for ages... how long is this thread now? It would be great if there was another alternative to this module because it is buggy and that's a fact. There is no problem with a fresh Drupal install if it is one of the first modules installed. But as you keep adding modules this will eventually break.

See #229. FileField isn't the problem, it's other modules screwing up the JS output when FileField is using AJAX uploads.

Luckily, D7 outputs a much more helpful error than "HTTP error 0" when this situation occurs, so hopefully this issue will eventually die as more people move to D7. ;)

I am pleased to report that I have finally identified the conflicting module that is causing the problem (for me anyway) and it is the RDF module. FileField does not appear to be compatible with RDF. Are you all using the RDF module? Now that I have identified this issue will the developers of both modules work together to resolve this issue? Or must we choose between using one module or the other?

@webchick - here's hoping. I'm getting tired of this issue being at the top of my feed :-/

It took much gnashing of teeth to get there, but in case it helps anyone, disabling GetID3 (and file field meta) solved this problem for me. I can live without those.

Subscribing, I have this problem when I use a localhost url to test the site which is different from the live site.
greetings, Martijn

subscribing

Subscribing, I use newest mods: imagefield 6.x-3.9, filefield 6.x-3.9 and cck-module 6.x-2.9. jQuery 1.3.2, pecl-upload is installed.. no solution yet.

A little bit confusing, in a seperate installation with same set-up works fine!

A little bit confusing, in a seperate installation with same set-up works fine!

Then most likely it's a difference in server configuration. See the two most common configurations to tweak in the Common FileField Problems handbook page.

@ #201 and #260 RE: SecurePages

This problem is not unique to this module and usually creeps up because a lot of modules use their own path for AJAX requests. Unfortunately, protocol switching is a very big nuisance for AJAX and is a security measure for cross-domain scripting. When SecurePages is installed, by default, if your pages are not supposed to be secure it will switch back to the non-secure, port 80 http, protocol. This isn't good if the page you're editing is utilizing the, port 443 https, protocol and makes a request to a URL that gets redirected.

We as developers should start recognizing that AJAX has become a very big part of the web and I think we should also start conforming to simplified AJAX URLs. I recommend modifying the beginning of FileField's AJAX menu path to start with 'ajax':

ajax/filefield                (from filefield/ahah)
ajax/filefield/progress       (from filefield/progress)

By default, SecurePages ignores protocol switching for the following matches (* being wild) and would allow this module to work out of the box if SecurePages is installed (or any other module that alters URLs and keeps in mind AJAX requests):

*/autocomplete/*
*/ajax/*

From my point of view,
I can compare at least my two instalation of drupal, first one installed in english, second one, installed in slowak. When I got my web installed in slowak version in root of apache document root, it all worked fine ( workspace/drupal_sk), after moving it in other directory (workspace/some_folder/drupal_sk) i got this problem. Funny thing is, that this never happened when I moved the english version of drupal (installed in english). I have no idea how to fix this strange behavior, maybe there is some bad setting with the paths or so. Has anyone idea if this could cause this problem ? thanx

strange for now it does not work in root of apache too :(

Issue tags:+autocomplete

So I've encountered the problem in a way a bit different than other people:
Per this issue: http://drupal.org/node/365241
I altered my autocomplete.js so that there was an "autocomplete_select" event.
I'm actually not sure if it's the root of the issue, but it I didn't see the problem before and the HTTP error comes out of my autocomplete callback url. The issue doesn't affect the actually submitting, but from a UI perspective it's awful to see that popup even without any consequence. Oddly enough this doesn't seem to raise a watchdog error.

I might do a work around where I override the submission mechanism and cause that to forward the user to a url. That's obviously not an ideal solution especially given Drupal's impressive Form API.

Here's what seems to be a related issue more close to the problems I've been having:
http://drupal.org/node/627834
however, I'm thinking if this problem is caused by the form submit interrupting the autocomplete, fileform problems might be due to fileform's callback being interrupted by form submit

I solved in a strange way but I did!

Please, take a look at this:

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

I've used #277 method to solving this and it looks like it did the trick.

Out of all the solutions that I have looked at I think this one is the easiest to implement. Whether if it is the best is outside my judgment.

Just to give some background to my version of this problem. I created an og gallery and when trying to upload an image using a non-user 1 account I would get the HTTP error 0.

Somebody emailed me the other day to see if I had solved this so I figured I should post an update here. I believe I've figured out the problem in my case. I'm hesitant to say I've figured it out for sure though because I've been at this stage a few times previously.

I found some errors related to my server's mod security in my error logs. I talked to my hosting company who whitelisted the uri in the error logs for the rule that was getting tripped. I'm still getting the error sporadically but think, or at least hope, I'm making progress.

solution pointed by comment #277 works great
can this be considered a fix ?

my situation:
get this error only on mozilla with imagefield / filefield sources / widget
remote upload

solution pointed by comment #277 works great
can this be considered a fix ?

The curious thing is I don't think that's actually a real "fix", it's probably covering up another problem (like server configuration issues) by using a work-around. You should never be returning a header of "text/html" instead of "javascript/json" (or "text/javascript") when returning a JSON object. Most likely changing the header to "text/html" makes it so that jQuery can accidentally parse the response correctly, because it's probably not valid JSON code being returned.

In any case, the line in question is in Drupal core. I would not be in support of such a solution.

subscribe

In my website suddenly i can not edit any views property the following error is showing please help me

An error occurred at /begin/admin/build/views/ajax/config-item/blog/default/field/comments_link.

Error Description: { "display": "\x3cform action=\"/begin/admin/build/views/ajax/config-item/blog/default/field/comments_link\" accept-charset=\"UTF-8\" method=\"post\" id=\"views-ui-config-item-form\"\x3e\n\x3cdiv\x3e\x3cdiv class=\"form-item\" id=\"edit-options-label-wrapper\"\x3e\n \x3clabel for=\"edit-options-label\"\x3eLabel: \x3c/label\x3e\n \x3cinput type=\"text\" maxlength=\"128\" name=\"options[label]\" id=\"edit-options-label\" size=\"60\" value=\"\" class=\"form-text\" /\x3e\n \x3cdiv class=\"description\"\x3eThe label for this field that will be displayed to end users if the style requires it.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-exclude-wrapper\"\x3e\n \x3clabel class=\"option\" for=\"edit-options-exclude\"\x3e\x3cinput type=\"checkbox\" name=\"options[exclude]\" id=\"edit-options-exclude\" value=\"1\" class=\"form-checkbox\" /\x3e Exclude from display\x3c/label\x3e\n \x3cdiv class=\"description\"\x3eCheck this box to not display this field, but still load it in the view. Use this option to not show a grouping field in each record, or when doing advanced theming.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-alter-alter-text-wrapper\"\x3e\n \x3clabel class=\"option\" for=\"edit-options-alter-alter-text\"\x3e\x3cinput type=\"checkbox\" name=\"options[alter][alter_text]\" id=\"edit-options-alter-alter-text\" value=\"1\" class=\"form-checkbox\" /\x3e Rewrite the output of this field\x3c/label\x3e\n \x3cdiv class=\"description\"\x3eIf checked, you can alter the output of this field by specifying a string of text with replacement tokens that can use any existing field output.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-alter-text-wrapper\"\x3e\n \x3clabel for=\"edit-options-alter-text\"\x3eText: \x3c/label\x3e\n \x3ctextarea cols=\"60\" rows=\"5\" name=\"options[alter][text]\" id=\"edit-options-alter-text\" class=\"form-textarea resizable\"\x3e\x3c/textarea\x3e\n \x3cdiv class=\"description\"\x3eThe text to display for this field. You may include HTML. You may enter data from this view as per the \"Replacement patterns\" below.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-alter-make-link-wrapper\"\x3e\n \x3clabel class=\"option\" for=\"edit-options-alter-make-link\"\x3e\x3cinput type=\"checkbox\" name=\"options[alter][make_link]\" id=\"edit-options-alter-make-link\" value=\"1\" class=\"form-checkbox\" /\x3e Output this field as a link\x3c/label\x3e\n \x3cdiv class=\"description\"\x3eIf checked, this field will be made into a link. The destination must be given below.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-alter-path-wrapper\"\x3e\n \x3clabel for=\"edit-options-alter-path\"\x3eLink path: \x3c/label\x3e\n \x3cinput type=\"text\" maxlength=\"255\" name=\"options[alter][path]\" id=\"edit-options-alter-path\" size=\"60\" value=\"\" class=\"form-text\" /\x3e\n \x3cdiv class=\"description\"\x3eThe Drupal path or absolute URL for this link. You may enter data from this view as per the \"Replacement patterns\" below.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-alter-link-class-wrapper\"\x3e\n \x3clabel for=\"edit-options-alter-link-class\"\x3eLink class: \x3c/label\x3e\n \x3cinput type=\"text\" maxlength=\"128\" name=\"options[alter][link_class]\" id=\"edit-options-alter-link-class\" size=\"60\" value=\"\" class=\"form-text\" /\x3e\n \x3cdiv class=\"description\"\x3eThe CSS class to apply to the link.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-alter-alt-wrapper\"\x3e\n \x3clabel for=\"edit-options-alter-alt\"\x3eAlt text: \x3c/label\x3e\n \x3cinput type=\"text\" maxlength=\"128\" name=\"options[alter][alt]\" id=\"edit-options-alter-alt\" size=\"60\" value=\"\" class=\"form-text\" /\x3e\n \x3cdiv class=\"description\"\x3eText to place as \"alt\" text which most browsers display as a tooltip when hovering over the link.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-alter-prefix-wrapper\"\x3e\n \x3clabel for=\"edit-options-alter-prefix\"\x3ePrefix text: \x3c/label\x3e\n \x3cinput type=\"text\" maxlength=\"128\" name=\"options[alter][prefix]\" id=\"edit-options-alter-prefix\" size=\"60\" value=\"\" class=\"form-text\" /\x3e\n \x3cdiv class=\"description\"\x3eAny text to display before this link. You may include HTML.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-alter-suffix-wrapper\"\x3e\n \x3clabel for=\"edit-options-alter-suffix\"\x3eSuffix text: \x3c/label\x3e\n \x3cinput type=\"text\" maxlength=\"128\" name=\"options[alter][suffix]\" id=\"edit-options-alter-suffix\" size=\"60\" value=\"\" class=\"form-text\" /\x3e\n \x3cdiv class=\"description\"\x3eAny text to display after this link. You may include HTML.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-alter-target-wrapper\"\x3e\n \x3clabel for=\"edit-options-alter-target\"\x3eTarget: \x3c/label\x3e\n \x3cinput type=\"text\" maxlength=\"128\" name=\"options[alter][target]\" id=\"edit-options-alter-target\" size=\"60\" value=\"\" class=\"form-text\" /\x3e\n \x3cdiv class=\"description\"\x3eTarget of the link, such as _blank, _parent or an iframe\'s name. This field is rarely used.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv\x3e\x3cfieldset id=\"views-tokens-help\"\x3e\x3clegend\x3eReplacement patterns\x3c/legend\x3e\x3cp\x3eThe following substitution patterns are available for this display. Use the pattern shown on the left to display the value indicated on the right. Note that due to rendering order, you cannot use fields that come after this field; if you need a field not listed here, rearrange your fields.\x3c/p\x3e\x3cdiv class=\"item-list\"\x3e\x3ch3\x3eFields\x3c/h3\x3e\x3cul\x3e\x3cli class=\"first\"\x3e[title] == Node: Title\x3c/li\x3e\n\x3cli\x3e[view_node] == Node: Link\x3c/li\x3e\n\x3cli\x3e[body] == Node: Body\x3c/li\x3e\n\x3cli class=\"last\"\x3e[comments_link] == Node: Add comment link\x3c/li\x3e\n\x3c/ul\x3e\x3c/div\x3e\x3c/fieldset\x3e\x3c/div\x3e\x3cinput type=\"hidden\" name=\"options[alter][help]\" id=\"views-tokens-help\" value=\"\" /\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-alter-trim-wrapper\"\x3e\n \x3clabel class=\"option\" for=\"edit-options-alter-trim\"\x3e\x3cinput type=\"checkbox\" name=\"options[alter][trim]\" id=\"edit-options-alter-trim\" value=\"1\" class=\"form-checkbox\" /\x3e Trim this field to a maximum length\x3c/label\x3e\n \x3cdiv class=\"description\"\x3eIf checked, this field be trimmed to a maximum length in characters.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-alter-max-length-wrapper\"\x3e\n \x3clabel for=\"edit-options-alter-max-length\"\x3eMaximum length: \x3c/label\x3e\n \x3cinput type=\"text\" maxlength=\"128\" name=\"options[alter][max_length]\" id=\"edit-options-alter-max-length\" size=\"60\" value=\"\" class=\"form-text\" /\x3e\n \x3cdiv class=\"description\"\x3eThe maximum number of characters this field can be.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-alter-word-boundary-wrapper\"\x3e\n \x3clabel class=\"option\" for=\"edit-options-alter-word-boundary\"\x3e\x3cinput type=\"checkbox\" name=\"options[alter][word_boundary]\" id=\"edit-options-alter-word-boundary\" value=\"1\" checked=\"checked\" class=\"form-checkbox\" /\x3e Trim only on a word boundary\x3c/label\x3e\n \x3cdiv class=\"description\"\x3eIf checked, this field be trimmed only on a word boundary. This is guaranteed to be the maximum characters stated or less. If there are no word boundaries this could trim a field to nothing.\x3c/div\x3e\n\x3c/div\x3e\n\x3cdiv class=\"form-item\" id=\"edit-options-alter-ellipsis-wrapper\"\x3e\n \x3clabel class=\"option\" for=\"edit-options-alter-ellipsis\"\x3e\x3cinput type=\"checkbox\" name=\"options[alter][ellipsis]\" id=\"edit-options-alter-ellipsis\" value=\"1\" checked=\"checked\" class=\"form-checkbox\" /\x3e Add an ellipsis\x3c/label\x3e\n \x3cdiv class=\"description\"\x3eIf checked, a \"...\" will be added if a file

This is happening to me as well but on when using Safari, works fine in FF4.

Spent a bunch of time in this issue today. What fixed it was upgrading CCK to the latest 6.2.9 version. I did also update drupal core form 6.9 to 6.20 before hand but that did not do it. The Hacks above did not work for me other than the cck upgrade.

subscribe

subscribe

Thanks, hedinfoto :) Comment#285
Error was fixed after upgrading CCK.

After about 12 hours of fiddling with permissions, my file system, imagecache and my tmp folder – I solved this problem by upgrading from CCK 6.x-2.9 to 6.x-3.0-alpha3.

The first time I was faced with that problem I solved it by deactivating "split summary at cursor" in all of my nodes. Today I've been confronted again with this error message, though I haven't used the "split summary at cursor" option. However, it took me several hours to fix it; here's my solution: deactivate javascript in FF while uploading files to your Drupal website, that's all folks!

Greetz
Jürgen

There is some work going on in the issue queue of the Plupload module for Drupal, which I've found is the best way to upload files to drupal with no possibility of an HTTP 0 error (that I've witnessed anyways) and also allows multiple files, and you can just drag files from explorer to your edit form, it's very nice.

However right now it's designed to put each file into its own node. Some people are working on a branch of the module to allow it to upload multiple files into a single field that allows multiple values. I would also love to have that functionality on one of my sites, while on another site where I use node gallery I'm happy with it the way it currently works.

http://drupal.org/project/plupload
#880300: Decide on a plupload module roadmap
#929510: Upload multiple files to single node?
#1019170: D7 Bulk Upload File Field

FileField 6.x-3.10 => HTTP error 0 with google chrome, Firefox and seamonkey goes into WSOD.
Walk around #5 get the file uploaded.

In several websites I solved this problem by using ImageMagick instead of ImageAPI GD2.

Just wanted to share I had this same issue with Google Chrome... couldn't figure out, updating modules, disabling Image API's etc... still go no. Finally I asked myself what has changed since yesterday. I installed uTorrent and it came with a tool bar, removed it from Google Chrome, all of a sudden no more HTTP Error 0 on my drupal page. Works Perfect. Just a FYI!

Steve

A client was having the same problem, while attempting to upload images to his site. I checked the files and found that those causing the HTTP error 0 were not set to a resolution of 72 dpi, as they should have been for web viewing. Changing nothing else, I properly reset the sizes, and everything is fine now. I hope this is useful for someone pulling her/his hair out over this.

I disabled drupal for firebug and the error went away. If I were not under a time crunch I would investigate. Good Luck.

I love this update "This error can be caused by many, many different things"....

Here's an idea, make the error say something different depending on the circumstance...... Thanks for the headache(s).

@bdichiara - Unfortunately, it is incredibly difficult to display different errors in most circumstances, because when the error is returned by the server, there's not much (any) information about what happened.

One more post, and this issue will be pushing 300 posts, and entering the land of irrelevance. I really wonder if the issue should be closed to new comments. I think, if someone were to read every post, almost any 'error 0'-related error would be resolved :-)

I had the same issue with Google Chrome for Mac today. What fixed it for me was disabling the Google Extension EXIF Data which I had running. Apparently there was a Javascript conflict or something when imagefield wants to display the uploaded image.

All in all I was relieved it was not a security issue but only a javascript conflict on browser side. Hope this helps for anyone!

Pages