Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Original message:
When I upload a file, it alerts an window and says /[path]/filefield/ahah/[content type]/field_[field_name]/0
Update, after over 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
,max_input_time
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!
Comment | File | Size | Author |
---|---|---|---|
#226 | still-getting-upload-error-after-jquery-forms-update-to-latest-version.png | 12 KB | whistle |
#92 | 2003.jpg | 534.3 KB | elallara |
#12 | filefield297035.patch | 624 bytes | vladimir.dolgopolov |
Comments
Comment #1
oxhead CreditAttribution: oxhead commentedp.s
6.x-3.0-alpha3 has problems
6.x-3.0-alpha2 is ok
6.x-3.0-alpha1 is ok
Comment #2
sybesis CreditAttribution: sybesis commentedI have this problem too....
Can someone tell me what is this filefield-ahah-wrapper...
Comment #3
nd987 CreditAttribution: nd987 commentedSame 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.
Comment #4
platform8-1 CreditAttribution: platform8-1 commentedSame issue here. Important to note that only occurs in non admin account. Have all permissions set correctly. Alpha3 is essentially broken.
Comment #5
sybesis CreditAttribution: sybesis commentedApparently, 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.
Comment #6
adampasz CreditAttribution: adampasz commentedI 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.
Comment #7
pietia CreditAttribution: pietia commentedSame here. Even after setting ALL PERMISSIONS to new user.
Comment #8
webchickI don't have time to look into this just now, but subscribe.
Comment #9
jumpfightgo@groups.drupal.org CreditAttribution: jumpfightgo@groups.drupal.org commentedsubscribe
Comment #10
guojia CreditAttribution: guojia commentedSame problem....subscribe
Comment #11
vladimir.dolgopolov CreditAttribution: vladimir.dolgopolov commentedAs I can see the problem is in filefield_menu():
should be
Because filefield_edit_access() operates $field_name but [content type] passed instead.
The patch will be ready soon.
Comment #12
vladimir.dolgopolov CreditAttribution: vladimir.dolgopolov commentedThe patch.
Comment #13
oxhead CreditAttribution: oxhead commentedThanks, it fixes now!
Comment #14
capellicIf at first it doesn't work, clear Drupal cache, clear browser cache and then reload the form.
Thanks for the patch!
Comment #15
Moonshine CreditAttribution: Moonshine commentedVladimir's patch is correct, and you will need to clear Drupal's menu cache for it to take effect.
Comment #16
drewish CreditAttribution: drewish commentedthanks, committed to HEAD.
Comment #17
drewish CreditAttribution: drewish commentedComment #18
preyer CreditAttribution: preyer commentedSorry 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.
Comment #19
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #20
gb3k CreditAttribution: gb3k commentedgood 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
Comment #21
lierrework CreditAttribution: lierrework commentedif "Path settings" -> "[date-in-tz]" - if name of date not in english - directory have bad name and we have... this error
Comment #22
gb3k CreditAttribution: gb3k commentedHello,
----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
Comment #23
Moonshine CreditAttribution: Moonshine commentedWhen 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.
Comment #24
gb3k CreditAttribution: gb3k commentedthanks 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?
Comment #25
Moonshine CreditAttribution: Moonshine commentedAre you running CCK Fieldgroup Tabs by chance?
Comment #26
gb3k CreditAttribution: gb3k commentedNo, just the module Fieldgroup (version 6.x-2.0-rc7)
Comment #27
drewish CreditAttribution: drewish commentedneed a clear set of steps that i can use to reproduce this error. try disabling the devel module if it's enabled.
Comment #28
cwhitcoe CreditAttribution: cwhitcoe commentedI 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.
Comment #29
dargrego CreditAttribution: dargrego commentedMaybe 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.
Comment #30
pkej CreditAttribution: pkej commentedI 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.
Comment #31
pkej CreditAttribution: pkej commentedFails 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.
Comment #32
pkej CreditAttribution: pkej commentedIt 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.
Comment #33
rapsli CreditAttribution: rapsli commentedI 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.
Comment #34
pkej CreditAttribution: pkej commentedFor 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.
Comment #35
stieglitz CreditAttribution: stieglitz commentedHaving 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" }
Comment #36
dopry CreditAttribution: dopry commentedwtf?!?! 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.
Comment #37
jesseliberty CreditAttribution: jesseliberty commentedI am having this problem with Beta5, is there a patch for this in beta5?
Comment #38
Mr.Sollis CreditAttribution: Mr.Sollis commentedI 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.
Comment #39
Mr.Sollis CreditAttribution: Mr.Sollis commentedOk, 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.
Comment #40
engineering@networkltd.eu CreditAttribution: engineering@networkltd.eu commentedI 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
Comment #41
kenorb CreditAttribution: kenorb commentedThe same on alpha6.
Why is that?
Comment #42
kenorb CreditAttribution: kenorb commentedDowngrading to filefield-6.x-3.0-alpha2.tar.gz helps:)
Comment #43
kenorb CreditAttribution: kenorb commentedComment #44
kenorb CreditAttribution: kenorb commentedComment #45
kenorb CreditAttribution: kenorb commentedIssue still continue here => #329913: still HTTP error 0
Comment #46
chris7148 CreditAttribution: chris7148 commentedHi 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
Comment #47
onetwoten CreditAttribution: onetwoten commentedI 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.
Comment #48
jaypabs CreditAttribution: jaypabs commentedHere'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?
Comment #49
igorik CreditAttribution: igorik commentedHi
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
Comment #50
kotu CreditAttribution: kotu commentedHello,
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
Comment #51
mokargas CreditAttribution: mokargas commentedKotu: 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.
Comment #52
gmateos CreditAttribution: gmateos commentedhi 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.
Comment #53
pachacuti CreditAttribution: pachacuti commentedKoto and all,
I'm brand new to Drupal. I got this error uploading my second file. How do I change the PHP limit?
Thanks.
Comment #54
kenorb CreditAttribution: kenorb commentedEdit your php.ini and look for the settings.
Read more: http://drupal.org/node/100373
or Google more
Comment #55
TravisCarden CreditAttribution: TravisCarden commentedI 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.)
Comment #56
trailerparkopera CreditAttribution: trailerparkopera commentedSame 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.
Comment #57
trailerparkopera CreditAttribution: trailerparkopera commentedI just realized this was closed. I'll file a new one, with more findings.
Comment #58
bryanhidalgo CreditAttribution: bryanhidalgo commentedAfter 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.
Comment #59
quicksketchFCKeditor breaks all uploads. See #248146: File upload throws error on attach only when FCKeditor is on page.
Comment #60
mentat.fr CreditAttribution: mentat.fr commentedJust 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 ....
Comment #61
vpapadim CreditAttribution: vpapadim commentedI 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
Comment #62
pyxio CreditAttribution: pyxio commentedI have the same problem. But it does not work in any browser for me. /[path]/filefield/ahah/[content type]/field_[field_name]/0
Comment #63
engineering@networkltd.eu CreditAttribution: engineering@networkltd.eu commentedI 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
Comment #64
graper CreditAttribution: graper commentedI 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
Comment #65
tommyent CreditAttribution: tommyent commentedNothing works for me. Not one of the 6 browsers memory limits, addons ahhhhhhhhh!!!!!!!!!!!!
Comment #66
tommyent CreditAttribution: tommyent commentedChanging the image size a couple of times fixed this. The size has never been an issue before though.
Comment #67
Michael Fuchs CreditAttribution: Michael Fuchs commentedIf 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!
Comment #68
sentinelcz CreditAttribution: sentinelcz commentedThis 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.
Comment #69
sentinelcz CreditAttribution: sentinelcz commentedI Enabled (PECL uploadprogress)
I increased PHP memory limit from 64M to 256M
Problem gone.
I will test it again with another server.
Comment #70
mudd CreditAttribution: mudd commentedI 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.
Comment #71
pimok3000 CreditAttribution: pimok3000 commentedWith 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.
Comment #72
sentinelcz CreditAttribution: sentinelcz commentedI can confirm that problem was in enabled FF module linkification.
After disabling the module, upload works.
Comment #73
snowmountain CreditAttribution: snowmountain commentedFor 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.
Comment #74
runegamborg CreditAttribution: runegamborg commentedConfirmed!
For me it was the "smarterfox" addon. I disabled 'linkyfy tekst urls' and the problem went away.
Comment #75
tribsinpa CreditAttribution: tribsinpa commentedMy 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.
Comment #76
lonestar790 CreditAttribution: lonestar790 commentedHey 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
Comment #77
bserem CreditAttribution: bserem commentedsubscribing
I also have this problem with OPERA 10
IE8 works ok
Comment #78
frednwright CreditAttribution: frednwright commentedSame thing for me with FireFox. Disabling the Browser Highlighter Add-on fixed it! (why?, I have no idea).
Comment #79
Elijah LynnDisabling 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/
Comment #80
Leech CreditAttribution: Leech commentedDisabling Devel module worked for me on Firefox 3 on Mac.
Safari failed (no error but uploading never ends).
Comment #81
k74 CreditAttribution: k74 commentedMemory limit at 128M and with Opera 10 Fails, with Firefox 3.5.3 OK
PECL not installed
Comment #82
Axel Pressbutton CreditAttribution: Axel Pressbutton commentedSubscribing
# Same issue as k74
Comment #83
amedee-1 CreditAttribution: amedee-1 commentedSubscribing.
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.
Comment #84
cyaneo CreditAttribution: cyaneo commentedSubscribing.
Same problem with Filefield 6.x-3.2 in Firefox 3.5.3 on Windows, no problem in IE8 on Windows.
Comment #85
Anonymous (not verified) CreditAttribution: Anonymous commentedSubscribing.
Same problem with Filefield 6.x-3.2 in Firefox 3.5.3 on OS X.
Comment #86
wibe CreditAttribution: wibe commentedSubscribing.
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.
Comment #87
Anonymous (not verified) CreditAttribution: Anonymous commentedMy 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.
Comment #88
bredi CreditAttribution: bredi commentedI had issues with my /tmp folder having too many half uploaded files. I removed them and things are fine now.
Comment #89
timcosgrove CreditAttribution: timcosgrove commentedI 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.
Comment #90
danschaller CreditAttribution: danschaller commentedI 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!
Comment #91
MadOverlord CreditAttribution: MadOverlord commentedMy 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.
Comment #92
elallara CreditAttribution: elallara commentedIt 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 #93
AaronM CreditAttribution: AaronM commentedComment 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!
Comment #94
joshuautley CreditAttribution: joshuautley commented#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!
Comment #95
okokokok CreditAttribution: okokokok commentedExperiencing 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.
Comment #96
okokokok CreditAttribution: okokokok commentedThe 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.
Comment #97
scrimmage CreditAttribution: scrimmage commentedfor me on os x error only occurs using Opera (10.10) but not Firefox 3.5 or Safari 4.03.
Comment #98
Ashraf Amayreh CreditAttribution: Ashraf Amayreh commentedHello 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:
The exception description, very surprisingly, is this:
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.
Comment #99
joachim CreditAttribution: joachim commentedI am seeing this error with the latest filefield too.
Comment #100
joachim CreditAttribution: joachim commentedI 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.
Comment #101
garywiz CreditAttribution: garywiz commented@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:
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.)
Comment #102
Ashraf Amayreh CreditAttribution: Ashraf Amayreh commentedI'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
Comment #103
garywiz CreditAttribution: garywiz commented@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:
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.
Comment #104
jhodnett2 CreditAttribution: jhodnett2 commentedYep!
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!
Comment #105
markus_cz CreditAttribution: markus_cz commentedGlad 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
Comment #106
garywiz CreditAttribution: garywiz commented@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.
Comment #107
bird-cage CreditAttribution: bird-cage commentedSubscribing
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.
Comment #108
rambo2000 CreditAttribution: rambo2000 commentedUpping 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.
Comment #109
skozik CreditAttribution: skozik commentedI was getting this problem. Solution was to disable the Devel module. Fixed it on FF 3.5.7 Mac OS 10.5.8.
Comment #110
redpuma CreditAttribution: redpuma commentedJust 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
Comment #111
chrismoylan CreditAttribution: chrismoylan commentedSubscribing.
Content editors notified me of this error, although I was unable to reproduce it.
Comment #112
smalek CreditAttribution: smalek commentedHello, 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
Comment #113
my-family CreditAttribution: my-family commentedSubscribing. 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.
Comment #114
babbage CreditAttribution: babbage commentedFor 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...
Comment #115
redpuma CreditAttribution: redpuma commentedJust 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.
Comment #116
digi24 CreditAttribution: digi24 commentedYes, IE works, chrome does not. I grepped through the files, but could not find any document.domain settings in enabled modules
Comment #117
machinez CreditAttribution: machinez commentedHad 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
Comment #118
Flying Drupalist CreditAttribution: Flying Drupalist commentedSame as redpuma, not working in Chrome. Works in FF.
Comment #119
mansspams CreditAttribution: mansspams commentedsame as redpuma @ #115 here, only with taxonomy autocomplete too
Comment #120
JordanMagnuson CreditAttribution: JordanMagnuson commentedI 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.
Comment #121
mansspams CreditAttribution: mansspams commentedThis 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).
Comment #122
my-family CreditAttribution: my-family commentedIn my case, the error is the same both with "www" and without it.
Comment #123
digi24 CreditAttribution: digi24 commentedThanks 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.
Comment #124
srobert72 CreditAttribution: srobert72 commentedSubscribing
Comment #125
srobert72 CreditAttribution: srobert72 commentedI have last version of "devel module" 6.x-1.x-dev (2010-Feb-14).
Disabling it solves my problem.
Comment #126
redpuma CreditAttribution: redpuma commentedJust disabled Devel and still no joy (in Chrome).
Comment #127
srobert72 CreditAttribution: srobert72 commentedDisabling DEVEL solved in Firefox 3.6, still problem in Opera 10.10.
Comment #128
JordanMagnuson CreditAttribution: JordanMagnuson commentedSo 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?
Comment #129
schedal CreditAttribution: schedal commentedMy 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!
Comment #130
Nazzto CreditAttribution: Nazzto commentedTry using another browser. It happend to me when using Iron SW (chrome), but get solved when using Firefox.
Comment #131
Flying Drupalist CreditAttribution: Flying Drupalist commentedIt'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.
Comment #132
Anonymous (not verified) CreditAttribution: Anonymous commentedThis 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.
Comment #133
digi24 CreditAttribution: digi24 commented@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.
Comment #134
JaMo CreditAttribution: JaMo commentedAn 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.
Comment #135
ˇh2nk CreditAttribution: ˇh2nk commentedChanging Browser solved my problem , deam i also tried every move.
Comment #136
snatcher CreditAttribution: snatcher commentedJust wanted to add that I encountered this problem in Firefox, and disabling the linkification extension solved my problem.
Comment #137
boazr CreditAttribution: boazr commentedSame error.
Multi-site installation, *only on IE* (8 and 7comp), permissions are fine (works ok with other browsers).
Comment #138
durum CreditAttribution: durum commentedsubscribing
Comment #139
webnation CreditAttribution: webnation commentedsubscribing
Comment #140
stealthguitar CreditAttribution: stealthguitar commentedI 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. :(
Comment #141
quicksketchThis 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.
Comment #142
kbalderson CreditAttribution: kbalderson commentedComment #143
jghyde CreditAttribution: jghyde commentedfor 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:
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
Comment #144
jghyde CreditAttribution: jghyde commentedLine 470 of vimeo.module is the closing bracket on this code snip:
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:
and
And then I found this http://drupal.org/node/613918 about D7 and the functions file_create_path() and file_check_directory()
Comment #145
jghyde CreditAttribution: jghyde commentedI 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
Comment #146
anyr CreditAttribution: anyr commentedSame as @joachim, the error disappeared for me if I resized the (image) file manually first. It's a CCK file field.
Comment #147
mammasan CreditAttribution: mammasan commentedHI 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
Comment #148
Anonymous (not verified) CreditAttribution: Anonymous commentedHi 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.
Comment #149
mammasan CreditAttribution: mammasan commentedThanks 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.
Comment #150
JennySmith CreditAttribution: JennySmith commentedDisabling Source Domain worked for me, fwiw.
Comment #151
FreddieK CreditAttribution: FreddieK commentedI 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.
Comment #152
Anonymous (not verified) CreditAttribution: Anonymous commentedThe 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. :-)
Comment #153
tpainton CreditAttribution: tpainton commentedI 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.
Comment #154
quicksketchIf 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.
Comment #155
Flying Drupalist CreditAttribution: Flying Drupalist commentedWhat about the upload bug that only occurs in Chrome but not Firefox?
IMO that's something to do with code.
Comment #156
Exploratus CreditAttribution: Exploratus commentedI 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?
Comment #157
donquixote CreditAttribution: donquixote commentedoh cool, yet another one, count me in :)
http://drupal.org/project/issues/search?issue_tags=ajax%20upload%20problem
Comment #158
mattwmc CreditAttribution: mattwmc commentedDitto
Comment #159
hbevan CreditAttribution: hbevan commentedsubscribing
Comment #160
nicoloconte CreditAttribution: nicoloconte commentedsubscribing, I have this error only with Google Chrome
Comment #161
jarednielsen CreditAttribution: jarednielsen commentedNearly 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
Comment #162
sunchaser CreditAttribution: sunchaser commentedstill have this issue after upping mem limit in php5.ini , .htaccess and settings.php to 96M
subscribing
Comment #163
sunchaser CreditAttribution: sunchaser commentedMan 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 !
So, what I did to work things out was :
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.
Comment #164
quicksketchEssentially 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.
Comment #165
Hanno CreditAttribution: Hanno commentedAfter a lot of experimenting, the following hack worked perfect for me:
change in filefield.module line 478:
to
Comment #166
sunchaser CreditAttribution: sunchaser commentedIn 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.
Comment #167
Hanno CreditAttribution: Hanno commentedI 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)
Comment #168
drewish CreditAttribution: drewish commentedhanno, 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?
Comment #169
agileadamI 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)
Comment #170
Hanno CreditAttribution: Hanno commented@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.
Comment #171
my-family CreditAttribution: my-family commented@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?
Comment #172
Hanno CreditAttribution: Hanno commented@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.
Comment #173
mparker17Subscribe
Comment #174
Flying Drupalist CreditAttribution: Flying Drupalist commentedLeast anyone think this problem is mystical, it's also present on d.o itself.
Try to upload something with chrome into the comment attachment.
Comment #175
RedTop CreditAttribution: RedTop commentedsubscribe
Comment #176
advseb CreditAttribution: advseb commentedsubscribe
Comment #177
lolmaus CreditAttribution: lolmaus commentedI'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.
Comment #178
unc0nnected CreditAttribution: unc0nnected commented"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
Comment #179
unc0nnected CreditAttribution: unc0nnected commentedSo 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...
Comment #180
anghor CreditAttribution: anghor commentedI'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?
Comment #181
qinwubi CreditAttribution: qinwubi commentedI'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.
Comment #182
qinwubi CreditAttribution: qinwubi commentedok. 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
Comment #183
digi24 CreditAttribution: digi24 commented#182 did not solve the problem for me. (yes, I made sure that caches are cleared and the updated library is loaded)
Comment #184
unc0nnected CreditAttribution: unc0nnected commentedIn 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
Comment #185
sajjadrobin CreditAttribution: sajjadrobin commentedChange the browser, I wasted my 40 hours solving this weird thing. But as soon as I changed FF to IE, it's working fine!!
Comment #186
magicRoot CreditAttribution: magicRoot commentedIt 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.
Comment #187
Flying Drupalist CreditAttribution: Flying Drupalist commented@magicRoot I do believe that's it. 0.o
Any solutions though?
Comment #188
magicRoot CreditAttribution: magicRoot commentedThe 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?
Comment #189
moreorless CreditAttribution: moreorless commentedI 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.
Comment #190
scarvajal CreditAttribution: scarvajal commentedI have the same problem with Chrome 5.x and also have smothscrolling extension installed. I confirm that disabling that extension the problem is solved.
Comment #191
kongoji CreditAttribution: kongoji commentedsubscribe
Comment #192
adrianmak CreditAttribution: adrianmak commentedsubscribing, I have this error only with Google Chrome without SmoothScroll extension installed.
Comment #193
cicciobombolo CreditAttribution: cicciobombolo commentedI have the same problem with IE and Firefox. Tried many things #182 #184 did not work for me
I have drupal 6.17
Comment #194
pyxio CreditAttribution: pyxio commentedThis 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
Comment #195
cicciobombolo CreditAttribution: cicciobombolo commentedHello 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!
Comment #196
k_and_j CreditAttribution: k_and_j commentedSame 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:
My php.ini (shared hosting):
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)
Comment #197
quicksketchYou'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.
Comment #198
k_and_j CreditAttribution: k_and_j commented@197 - I checked with my host and also phpinfo(). Also, admin/settings/uploads says it is 10MB, not 2MB.
Comment #199
k_and_j CreditAttribution: k_and_j commentedOK - 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.
Comment #200
ISPTraderChris CreditAttribution: ISPTraderChris commentedI 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.
Comment #201
rjbrown99 CreditAttribution: rjbrown99 commentedOne 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.
Comment #202
Majdi CreditAttribution: Majdi commentedWell 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 !
Comment #203
kiwad CreditAttribution: kiwad commentedThanks 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
Comment #204
quicksketchSeems 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.
Comment #205
timwoodWe'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
Comment #206
As If CreditAttribution: As If commentedI'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.
Comment #207
plazma CreditAttribution: plazma commentedHI 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
Comment #208
geerlingguy CreditAttribution: geerlingguy commentedIncreasing 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:
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.
Comment #209
bradklaver CreditAttribution: bradklaver commentedJust 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!
Comment #210
Anonymous (not verified) CreditAttribution: Anonymous commentedSince "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?
Comment #211
donquixote CreditAttribution: donquixote commented#210 (genox):
Have a look at
#646694: AJAX: Terrible reporting of status 0 response from AJAX request ("HTTP Error 0 has occurred")
still needs D6 port, I think.
Comment #212
liquidcms CreditAttribution: liquidcms commentedbattling 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.
Comment #213
Anonymous (not verified) CreditAttribution: Anonymous commented@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.
Comment #214
kpv CreditAttribution: kpv commentedit 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'
Comment #215
valderama CreditAttribution: valderama commentedimage 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.
Comment #216
valderama CreditAttribution: valderama commentedI 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.
Comment #217
seanwallis CreditAttribution: seanwallis commentedI 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
Comment #218
Drupal webdesigner CreditAttribution: Drupal webdesigner commentedThis 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.
Comment #219
pixelpreview@gmail.com CreditAttribution: pixelpreview@gmail.com commentedThe 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
Comment #220
sweir CreditAttribution: sweir commentedAdd 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.
Comment #221
sarahjean CreditAttribution: sarahjean commentedThe 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.
Comment #222
NickWebman CreditAttribution: NickWebman commentedwhat worked for me: I was attempting to upload an image that was too big... Once I shrunk and compressed it, all was well.
Comment #223
Crom CreditAttribution: Crom commentedI 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.
Comment #224
whistle CreditAttribution: whistle commentedHi Sentinelcz,
How did you go about enabling PECL Upload progress?
Is it relatively easy and did it definitely resolve the issue?
Thanks
Comment #225
ericG CreditAttribution: ericG commentedI 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.
Comment #226
whistle CreditAttribution: whistle commentedHi qinwubi
I tried upgrading the jquery.form.js - to Version: 2.52 (07-DEC-2010)
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.
Comment #227
m.sant CreditAttribution: m.sant commentedFileField [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
Comment #228
Stomper CreditAttribution: Stomper commentedSo 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
Comment #229
quicksketch@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.
Comment #230
oskarblue CreditAttribution: oskarblue commentedI 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.
Comment #231
TravisCarden CreditAttribution: TravisCarden commented@oskarblue: Remember that the "Issue title" and other fields on the comment form change details of the entire issue. :)
Comment #232
Stomper CreditAttribution: Stomper commentedI 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.
Comment #233
Stomper CreditAttribution: Stomper commentedSorry all, I changed the issue title with my previous post. This post was intended to return it to the original issue title.
Comment #234
kalpanavk CreditAttribution: kalpanavk commentedunable to upgrade filefield 3.7 to 3.9.
Comment #235
kalpanavk CreditAttribution: kalpanavk commentedunable to upgrade version.
Comment #236
parasox CreditAttribution: parasox commentedGetting 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.
Comment #237
Flying Drupalist CreditAttribution: Flying Drupalist commentedIf you're getting the problem only in 1 browser, check ur extensions.
Comment #238
sockah CreditAttribution: sockah commentedI'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.
Comment #239
sockah CreditAttribution: sockah commentedThis 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.
Comment #240
pyxio CreditAttribution: pyxio commentedIt 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.
Comment #241
sockah CreditAttribution: sockah commentedYep, 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.
Comment #242
dvatri CreditAttribution: dvatri commentedGot 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?
Comment #243
sockah CreditAttribution: sockah commentedInteresting, 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.
Comment #244
jjoseph CreditAttribution: jjoseph commentedWhat 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!
Comment #245
parasox CreditAttribution: parasox commentedThat 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.
Comment #246
sockah CreditAttribution: sockah commentedI 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
Comment #247
sockah CreditAttribution: sockah commentedCommenting 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.
Comment #248
timwoodsockah,
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
Comment #249
sockah CreditAttribution: sockah commentedThanks 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.
Comment #250
timwoodSorry, 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.
Comment #251
sockah CreditAttribution: sockah commentedAh thanks much Timwood. I'm guessing that isn't the problem/solution for me since I'm not using either of those modules.
Comment #252
parasox CreditAttribution: parasox commentedWhat'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.
Comment #253
quicksketch- 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.Comment #254
lolmaus CreditAttribution: lolmaus commentedI 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.
Comment #255
sockah CreditAttribution: sockah commentedQuicksketch, 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.
Comment #256
parasox CreditAttribution: parasox commentedSockah: 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.
Comment #257
sockah CreditAttribution: sockah commentedThanks 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?
Comment #258
parasox CreditAttribution: parasox commentedThe 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.
Comment #259
sockah CreditAttribution: sockah commentedThanks Parasox, I understand now. Fortunately, log_errors was already turned on. I'm going to start working through it for clues.
Comment #260
DamienMcKennaFYI I've put in a feature request with SecurePages to include the FileField paths by default: #1035670
Comment #261
crifi CreditAttribution: crifi commentedThis 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!
Comment #262
As If CreditAttribution: As If commentedNobody 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.
Comment #263
pyxio CreditAttribution: pyxio commentedThis 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.
Comment #264
webchickSee #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. ;)
Comment #265
pyxio CreditAttribution: pyxio commentedI 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?
Comment #266
geerlingguy CreditAttribution: geerlingguy commented@webchick - here's hoping. I'm getting tired of this issue being at the top of my feed :-/
Comment #267
sprugman CreditAttribution: sprugman commentedIt 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.
Comment #268
Summit CreditAttribution: Summit commentedSubscribing, I have this problem when I use a localhost url to test the site which is different from the live site.
greetings, Martijn
Comment #269
fildawg CreditAttribution: fildawg commentedsubscribing
Comment #270
fragtom CreditAttribution: fragtom commentedSubscribing, 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!
Comment #271
quicksketchThen most likely it's a difference in server configuration. See the two most common configurations to tweak in the Common FileField Problems handbook page.
Comment #272
markhalliwell@ #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':
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):
Comment #273
peter.milan CreditAttribution: peter.milan commentedFrom 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
Comment #274
peter.milan CreditAttribution: peter.milan commentedstrange for now it does not work in root of apache too :(
Comment #275
Jztinfinity CreditAttribution: Jztinfinity commentedSo 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.
Comment #276
Jztinfinity CreditAttribution: Jztinfinity commentedHere'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
Comment #277
gianfrasoft CreditAttribution: gianfrasoft commentedI solved in a strange way but I did!
Please, take a look at this:
http://drupal.org/node/491610#comment-4260902
Comment #278
McGrimm CreditAttribution: McGrimm commentedI'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.
Comment #279
sockah CreditAttribution: sockah commentedSomebody 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.
Comment #280
GiorgosKsolution 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
Comment #281
quicksketchThe 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.
Comment #282
focal55 CreditAttribution: focal55 commentedsubscribe
Comment #283
probal21 CreditAttribution: probal21 commentedIn 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
Comment #284
Clint Eagar CreditAttribution: Clint Eagar commentedThis is happening to me as well but on when using Safari, works fine in FF4.
Comment #285
hedinfoto CreditAttribution: hedinfoto commentedSpent 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.
Comment #286
powery CreditAttribution: powery commentedsubscribe
Comment #287
rolfmeijer CreditAttribution: rolfmeijer commentedsubscribe
Comment #288
christine1126 CreditAttribution: christine1126 commentedThanks, hedinfoto :) Comment#285
Error was fixed after upgrading CCK.
Comment #289
Greg J. Smith CreditAttribution: Greg J. Smith commentedAfter 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.
Comment #290
jottmalzwo CreditAttribution: jottmalzwo commentedThe 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
Comment #291
parasox CreditAttribution: parasox commentedThere 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
Comment #292
ronline CreditAttribution: ronline commentedFileField 6.x-3.10 => HTTP error 0 with google chrome, Firefox and seamonkey goes into WSOD.
Walk around #5 get the file uploaded.
Comment #293
my-family CreditAttribution: my-family commentedIn several websites I solved this problem by using ImageMagick instead of ImageAPI GD2.
Comment #294
BV1 CreditAttribution: BV1 commentedJust 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
Comment #295
geerlingguy CreditAttribution: geerlingguy commentedRemoving some one-off extraneous tags.
Comment #296
pixelsnap CreditAttribution: pixelsnap commentedA 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.
Comment #297
book_guy CreditAttribution: book_guy commentedI disabled drupal for firebug and the error went away. If I were not under a time crunch I would investigate. Good Luck.
Comment #298
bdichiara CreditAttribution: bdichiara commentedI 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).
Comment #299
geerlingguy CreditAttribution: geerlingguy commented@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 :-)
Comment #300
tiim_b CreditAttribution: tiim_b commentedI 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!
Comment #301
ankheg CreditAttribution: ankheg commentedHad this problem in Opera 11.50 (Drupal 6.20, Filefield 6.x.-3.9).
Installing http://drupal.org/project/jquery_form_update 6.x-1.0 and http://drupal.org/project/jsalter 6.x-1.0 solved the issue.
Comment #302
michael.lee.baker@gmail.com CreditAttribution: michael.lee.baker@gmail.com commentedYep - rolling back version of jquery to the one distributed with Drupal 6 fixed all my issues including the filefield remove button problem.
Comment #303
ronline CreditAttribution: ronline commentedWent through all php.ini setting finally end up with RDF.
No server settings, no max_filesize, no max_execution_time or whatever.
It is RDF! Deactivate RDF module fix the issue.
Comment #304
stefan81 CreditAttribution: stefan81 commented@ronline
what is RDF?
Comment #305
vensires CreditAttribution: vensires commentedIt may also be caused from Adblock Plus browser extension (see http://www.devcha.com/2010/...). Check your firebug console to be sure!
Comment #306
philsward CreditAttribution: philsward commentedWell, I'm going to throw in my $0.02 about the problem, since this seems like the most used forum for this error...
I migrated hosts from a shared server package (managed by host) to a VPS package (managed by me) and ran into this wonderful little problem... After about 2 hours of research, I ran across a wonderful blog post out on munkeyonline.co.uk with a handful of tips on how to possibly solve the error.
About halfway down the page is an area titled: "Check FastCGI config" which the author has a single line posted, fixing my issue: "add"
MaxRequestLen 15728640
to conf file/etc/httpd/conf.d/fcgid.conf
If you are on a cPanel hosting package, take a look at this forum comment on adding the "MaxRequestLen" to your "php.conf" file instead of the fcgid.conf file (or better yet, the
/usr/local/apache/conf/includes/pre_virtualhost_global.conf
I didn't add any of the other stuff listed there, but it might be useful)Seems to have fixed my problem and hope it fixes yours!
Comment #307
prcweb CreditAttribution: prcweb commentedI had the same problem whilst working through the Photo Gallery example in Using Drupal.
I opened the PHP error log (see phpinfo()'s error_log for the path) and saw:
so could see that it was simply a PHP memory size limit issue.
Hopefully this error log can help locate the problem for other users.
Comment #308
Millyfab CreditAttribution: Millyfab commentedGod, help me ! :'( I've already tried all these tricks without any success :
- comment/uncomment base_url in settings.php
- using jquery update module
- enabling upload module
- increasing memory, upload and post limit (memory : 256M, post and upload : 64M)
- changing files folders permissions
- updating jquery.form.js
- enabling cache in performance
- tried in different browsers
I can't even upload 32M files... And if I'm trying to upload +64M, I don't even get a warning which tells me
that the file is too big... I'm so hopeless...
Comment #309
powoul CreditAttribution: powoul commentedI recently ran into this error on a colleagues computer, and tried everything I could on this of comments.
My colleague was using Safari 5.1.3 for Mac OSX
It turned out to be the Evernote Safari Extension Plugin that was causing the problem, whenever we try to upload a file into a news item.
This extension also puts erroneous information in the FCKEditor that we were using as well. When clicking the source button on FCKEditor, it puts a load of code in there, instead of just the usual:
<p> </p>
I just wanted to post this here in case it helps anyone with this problem that took me a number of hours to track down going through settings and configs.
- powoul
Comment #310
geerlingguy CreditAttribution: geerlingguy commentedAdjusting tags.
Comment #311
Studio FJ CreditAttribution: Studio FJ commentedWe have been dealing with the issue of FileField not allowing us to upload more than 1MB files for several months, despite upping the servers upload limit and several other tweaks.
We finally reached a SOLUTION yesterday after 40+ hours of troubleshooting. We are on a MediaTemple Dedicated Virtual Server running Drupal 6.26.
We tried the following edits to the php.ini file:
upload_max_filesize = 64M post_max_size = 32M memory_limit = 32M max_execution_time = 300
That didn't work.
We tried implemented several patches from posts on Drupal.org. None of them worked for us.
And finally the SOLUTION for us was to update to the newest jquery.form.js file (released on 11/20/12) in one of the following directories:
/drupal/misc/jquery.form.js
or if you have the JQuery Update module installed:
/drupal/sites/all/modules/jquery_update/replace/jquery.form.js
The newest version can be found at:
http://malsup.github.com/jquery.form.js
Hope this helps!
http://studiofj.com
Comment #312
elparaiso CreditAttribution: elparaiso commentedThere's a module that allows you to use alternative ways to attach files to content apart from File fields upload-button - it allows FTP-uploads to be used directly in the field amongst others - works for me, and even bypasses the annoying upload limits.
http://drupal.org/project/filefield_sources
Note: You have to enable the alternative upload mechanisms you want to use in the appropriate content type's fields - D6 /admin/content/types/ -> [content-type] Manage fields
Comment #313
elparaiso CreditAttribution: elparaiso commentedThere's a module that allows you to use alternative ways to attach files to content apart from File fields upload-button - it allows FTP-uploads to be used directly in the field amongst others - works for me, and even bypasses the annoying upload limits.
http://drupal.org/project/filefield_sources
Note: You have to enable the alternative upload mechanisms you want to use in the appropriate content type's fields - D6 /admin/content/types/ -> [content-type] Manage fields
Comment #314
law99 CreditAttribution: law99 commentedNot sure how much use this will be this late in the game but:
In my case this issues was caused by IIS 7 webconfig file not reflecting the upload size I set in PHP.ini. Details can be found here: http://www.webtrenches.com/post.cfm/iis7-file-upload-size-limits
IIS 7 has a default limit of 30MB.
Admittedly I didn't read all the comments, I just searched for IIS to see if there were any related issues. So sorry if mentioned before for bringing back dead threads.
Comment #315
Eloy CreditAttribution: Eloy commentedA customer updated his Plesk VPS and since then he was unable to upload files getting always this error.
I tried updating modules, commenting code in the filefield_widget.php, increasing the memory_limit, increasing post_max_size, increasing max_file_size, checking the URL rewriting, checking permissions, etc. until I finally found the Apache's error_log.
The message was clear:
[Wed Apr 10 11:02:53 2013] [warn] [client xxx.xxx.xxx.xxx] mod_fcgid: HTTP request length 133287 (so far) exceeds MaxRequestLen (131072), referer: http://xxx.xxxxxxx.xxx/node/xxx/edit
This solved my problem: http://www.faqforge.com/linux/fix-http-request-length-134926-so-far-exce...
I wish I would have read #306 before spending hours on this...
I hope this can help anyone else.
Comment #315.0
Eloy CreditAttribution: Eloy commentedSummarized very long thread of comments, as this is the issue that won't die.
Comment #316
primaxx CreditAttribution: primaxx commentedI just want to mention that with Drupal installed on ISPConfig on Ubuntu 12.04, this fixed the problem for me:
Add MaxRequestLen 15728640 to /etc/apache2/mods-available/fcgid.conf
so it looks like:
and restart Apache.
I fount the solution here.
Comment #317
cosolom CreditAttribution: cosolom commentedI solve this problem by update jquery.form.js to v3.17 (this is latest version with min requeriments jquery 1.3.2)
Comment #318
dreamer777 CreditAttribution: dreamer777 commentedFor me with PHP 5.3.3 I used all the options, but finally it was that PHP was used as FastCGI. I changed it to be used as Apache module in Plesk panel and it solved my problem.
I think that MaxRequestLen 15728640 would also help, but I did not try.
Comment #319
kevstev01 CreditAttribution: kevstev01 commentedFor those of you stuck on IIS (like me) I found an error in the PHP log file complaining about the maximum execution time 0 ( = infinite) being exceeded when uploading large files. I knew it was taking forever to upload, but that's ridiculous ;-)
Thanks to this post
http://www.sparrowtail.com/php-fatal-error-maximum-execution-time-0-seco...
I set max_input_time = -1 (unlimited) in the php.ini file and it resolved this HTTP error 0 issue for me.
HTH
Comment #320
kenorb CreditAttribution: kenorb commentedComment #321
openmode CreditAttribution: openmode commentedEnvironment configuration:
Drupal 6.31
GD library bundled (2.0.34 compatible)---
PHP memory limit 1024M
PHP 5.3.3
webserver Apache/2.2.3 (Red Hat)
When I try to upload a file with fileupload widget appear this message:
An HTTP error 0 occurred.
/filefield/ahah/[content_type_name]/[field_name]/0
The message appears with standard Firefox 29.0 on OS X 10.9.2
even if I use plupload, iTweekUpload, ecc...modules
even with Filefield 3x.12, Filefield 3x.11, Filefield 3x.10 ecc..
The message doesn't appears with:
Safari 7.0.3 on OS X 10.9.2
Internet Explorer 11.0.7 on Windows 7
Firefox 28.0 on Windows 7
Firefox 29.0 on Windows 7
Internet Explorer 11.0.9 on Windows 8.1
Chrome 34.0.1 on Windows 8.1
Firefox 28.0 on Windows 8.1
Comment #322
StephanMoe CreditAttribution: StephanMoe commentedDrupal 6.31 comes with "/misc/jquery.form.js" version 2.01 from waaaay back. Updating "jquery.form.js" to version 2.32 (17-SEP-2009) from github fixed the HTTP-0 error for me.
Comment #323
selwynpolit CreditAttribution: selwynpolit commentedBattling this error now. Sad to say I have a client with a Drupal 6 install and I can't get this problem to go away. Has anyone seen this lately? I downloaded a fresh jquery.form.js and replaced the one in drupal's misc directory but I get "the connection was reset" when I try to upload an image.
I'm not having any luck finding the updated ver 2.32 jquery.form.js on github. Can anyone give me a URL to that?
thanks
Selwyn
Comment #324
pwolanin CreditAttribution: pwolanin as a volunteer and at Acquia commented