Posted by khurrami on 

I have installed all the required modules

and set the upload_max_filesize = 200M in php.ini file

But still I am facing the following error

"An HTTP error 0 occurred. ?q=filefield/ahah/product/field_picture/0"

when i try to upload a product images.

plz let me know about the solution

thanks

⋅ Categories: Drupal 6.x

Comments

jasonsavino’s picture

jasonsavino commented 

are you using devel? if so, turn it off, refresh your browser and try again. seriously, that was all it took for me on my system. I turned devel back on and it errored again. I repeated this 25 time and got the same results every time.

Cheers,
Jason

joshuautley’s picture

joshuautley commented 

I have read all the replies on the other areas regarding this issue, but the fact is it is still an issue.

trentharlem’s picture

trentharlem commented 

Same Error... An HTTP error 0 occurred. /filefield/ahah/...
I do not have Devel installed.
I discovered the issue when trying to update an existing views-slideshow with some new images.
Any Ideas?

trentharlem’s picture

smartfun commented 

To avoid this kind of error try to reduce the size of the photo you want to upload. I've done this with Photoshop, where is a function for saving the fotos for web and devices. The problem is solved.
Regards.

trentharlem’s picture

sadist commented 

having the same problem when a normal authenticate user trying to upload a 40MB video file to filefield.

An HTTP error 0 occurred.
http://www.drupalsite.com/filefield/ahah/video/field_video/0

My webserver is set upload_max_filesize = 500M

NonProfit’s picture

NonProfit commented 

Me too.

I'm running 6.15 on localhost and have created a simple content type (title, image). My site can take a very tiny images (12k), but provides an HTTP error 0 when given what is still a small image upload (3.5MB). I'm using ImageAPI GD2 6.x-1.6 to process.

ANY input greatly appreciated.

Thanks!

-NP

NonProfit’s picture

NonProfit commented 

Note: This may be an issue with PHP memory.

I added:

ini_set('memory_limit', '128M' );

to settings.php and the issue seems to have resolved itself.

Note: Obviously, 128M may or may not be the appropriate setting for you, and unfortunately even if it is, this doesn't work on all serves. Here is more info and a couple other techniques on how to increase your PHP's memory.

Blessings!

-NP

trentharlem’s picture

20footduck commented 

Updating settings.php seems to have done the trick for me also, thanks! :)

trentharlem’s picture

sadist commented 

I can't manage to explain on this, as not all machines can produce the same bug. It will only happen with SOME machines running Mozilla Firefox, but not all. With the same Windows machines that having this issue with Firefox, didn't have problem if it's by another browser.

But some other Windows machines has no problem with it at all.

trentharlem’s picture

chocolatfrog commented 

have the same problem this morning.

I have an image that weight 1 Mo my uplaod image limit is 2 Mo

I check if my jpg wasnt corrupted copy/paste it as a new image and try to reuplaod it still the filefield/ahah/... message

then I resize my image that was 3700x5600 for 1500x1000 and I succeed to upload it

tho I see nowhere where there is a limint in the resolution

olafkarsten’s picture

olafkarsten commented 

There are several threads about this error/problem and no simple solution. It seems that this error can have several totally different causes. In my case it was an browser addon - chrome -> addon "SelectToGetMaps". That was really a pain to find out. Maybe in other browser addons can be the cause, too. Better you test it with a plain installation. Good Luck!

finaukaufusi’s picture

finaukaufusi commented 

Any solution for this problem, I got this problem and I can't think anymore.
I've had create my upload image module. When I click the upload button I got the above error message. In the background, my image upload script is still successfully uploaded the image file but it does display the popup weird javascript message ( we might ask the JQuery people to help)

Any ninja out there ?

finaukaufusi’s picture

finaukaufusi commented 

I told you guys, it's all about jquery.

Here's the solution and it might help someone outhere.

I download the latest jquery.form.js fromhttp://jquery.malsup.com/form/#download

And replace the jquery.form.js on /drupal/misc/jquery.form.js

Now my module is works..what a wonderful day for me :)

trentharlem’s picture

tomlam commented 

I tried this method and the same problem remains.

The file i'm uploading is only 1mb so I dont see that it could be a memory issue. Is there any other answer?

trentharlem’s picture

codeglyph commented 

tried with the downloaded version and the error seems to be gone. Anyway this may not work for everybody since the

'http 0 ' error may arise from different causes

- at least that's what people say . That's why it tends to be solved by so many patches and quirks.

thnx finau.
HOWEVER: the new jquery.form.js breaks the OTHER ahah functionality.

trentharlem’s picture

vitis commented 

sub

trentharlem’s picture

sunchaser commented 

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

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

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

The lines that provided the ahah wrapper where commented out !

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

So, what I did to work things out was :

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

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

trentharlem’s picture

aleighs commented 

I was having the same issue with filefield - file type and commenting out the ahah wrapper also fixed my issue which occurred under very specific circumstances on only one content type with certain roles.

Note: There are actually two places you need to comment out, both filefield_upload and filefield_remove.

I am using filefield extensively with the same permission and roles without any errors on other content types.

However, I too need to know what the purpose of the ahah wrapper functionality is and if I'm causing other issues.

trentharlem’s picture

eforth commented 

Thanks for this hardcore solution!

jnettik’s picture

jnettik commented 

Yeah this worked for me too. I was a little confused about what your instructions were though. You said when you went to the file it was commented out then you had to again comment it out to get it to work?

In my file the #ahah wrapper was uncommented and i had to comment it.

As far as the functionality, I'm not an expert on it but it looks like it just doesn't use ajax to upload the image. The page seems to refresh when you add a new image. I'll be interested to hear if there are any other repercussions to this fix as well.

skruf’s picture

skruf commented 

Worked for me as well. Thanks for saving me hours digging through the code. Hope it gets fixed in next release.

trentharlem’s picture

sypl commented 

Because this actually WORKS! Was having no problems in anything but Chrome, and this fix made everything alright.

The parts commented out are an option for fancy AJAX fade effects on upload and removal of images. Without it the page reloads, throwing a warning message if other required fields haven't been entered yet. All a bit 90s, and slows down the process for the user a bit, but still, I think I can live with that loss for functionality that works every time.

This seems to be a problem with browsers though, as numerous people have reported the functionality to work fine with all browsers but one or two. So very, very odd. Clash with a Chrome extension maybe?

trentharlem’s picture

sypl commented 

Google Chrome's Chrome Gestures to be precise:https://chrome.google.com/webstore/detail/jpkfjicglakibpenojifdiepckckakgk

Disabling it or just running in incognito mode makes everything run fine. Maybe it's something to do with the order that Chrome processes javascript. No such problem in Safari, so I presume this is not a webkit problem.

For anyone else who can't get this working in just the one browser, try running without any extensions to see if that helps.

monstordh’s picture

monstordh commented 

The culprit for me was the Swagbucks Toolbar for Chrome that I recently installed. Once I turned this extension off, it all worked fine.

jberg1’s picture

jberg1 commented 

I'm not sure everything this does. But when I comment it out, I notice I no longer get the little spinning stop watch next to the upload button after click. And after it does upload the image it refreshes the whole page (maybe saving it?).

It's kind of nice when it stays in the position with the little spinning stop watch, but this solution is better than getting the errors.

Thanks!!

trentharlem’s picture

ThaboGoodDogs commented 

Yes, this work. Little 3 hour stints like this where I'm basically working for free is why I switched to Wordpress :) Still got some Drupal sites to mess with and I miss the old girl! Not looking forward to upgrading this mess to Drupal 7 :(

trentharlem’s picture

jzerpa commented 

This worked!!

Thanks!

trentharlem’s picture

fyberoptik commented 

This fix didn't directly address my issue, but it did flag a '413 Request Entity Too Large' in nginx. Probably should checked the error logs a bit more closely.

Anyway, added the following line to my nginx site config, in the available sites folder:
client_max_body_size 20M;

I then could comment the ahah code back in and, BAZINGA, it worked.

Big thanks

trentharlem’s picture

trentharlem commented 

My fix came from uninstalling and reinstalling all relevant modules (some with new updated versions). I cant explain it but it worked.

trentharlem’s picture

Mars2012 commented 

subcribing

SpartyDan’s picture

SpartyDan commented 

I upgraded from filefield 3.3 to 3.4 it broke my site and gave me the same "HTTP error". When I downgraded to 3.3 my site started working again.

trentharlem’s picture

hallaathrad commented 

*Subscribing*

jnettik’s picture

jnettik commented 

I added a field for image uploads to the page content type on my site. Now what confuses me is that every page has no problems except one. And now if I go to create a new page, I get that error. Any ideas?

Edit: I needed to use the fix mentioned earlier about commenting out the #ahah wrapper.

trentharlem’s picture

modernaut commented 

I've tried all of the above mentioned to date -- I still get the error when trying to remove an image.

There are only 2 nodes (out of a hundred or so), that are known to be affected.

Currently running:
- FileField 6.x-3.7

Other dependent modules:
- Image crop 6.x-1.0-rc2
- ImageField 6.x-3.0

I had experienced the same issue with earlier versions of FileField and Image Crop before upgrading. I also disabled Image crop and still had the same problem.

Your help is *greatly* appreciated.

kevinwalsh’s picture

kevinwalsh commented 

i found that by disabling the "linkification" plug-in for FF 3.6.10 on Mac this error went away, on several sites.

-kev

trentharlem’s picture

mrwhizkid commented 

Make sure you are using the latest version of CCK! I had this same problem a couple of days ago...but I was using an older version of CCK. Upgraded to the new version and the problem was gone!

trentharlem’s picture

zincdesign commented 

Adding:

ini_set('memory_limit', '128M' );

to the setting.php sorted the problem for me too. Thanks "NonProfit"

mike dodd’s picture

mike dodd commented 

Firebug was causing it for me closed it all fine

If Windows is the answer, it must have been a stupid question. -- Filip Van Raemdonck

ishmael-sanchez’s picture

ishmael-sanchez commented 

If the getid3 module isn't properly installed you might get this error. Hopefully this helps someone.

trentharlem’s picture

MortenP commented 

A bad install of getid3 ruined half my day. All is well now

trentharlem’s picture

jibberish commented 

I fixed this by doing the following:

Upgrading from filefield-6.x-3.7 to filefield-6.x-3.9.

I then reset all my caches and it started working.

trentharlem’s picture

royerd commented 

Thank you Jibb. It's interesting how we look and look for answers to a problem, and we are prejudiced against some solutions for some odd reason. I, for some reason, insisted to myself that updating that module was not the problem. It was. Thanks. --Dan

trentharlem’s picture

jibberish commented 

:-)

trentharlem’s picture

cozza13 commented 

After trying every other fix with no luck the fix that made it work for me was turning of Devel and show memcache stats on page. I found the solution by trial and error

trentharlem’s picture

mrwhizkid commented 

That's a good point...if you're using memcache admin stats module, you'll get that problem.

Also, if you're using cacherouter with APC you need to make sure and exclude the cache_form table (use db to cache it) or you will also have this problem.

trentharlem’s picture

dotsam commented 

Disabling memcache stats worked for me! Thank you.

Makakman’s picture

Makakman commented 

Increasing the php memory limit solved the issue for me which wasn't shown in recent log entries but was shown in the server error logs.

trentharlem’s picture

TimelessDomain commented 

Here's how I fixed it:

I just commented out the base_url line in settings.php (around line 127):

$base_url = 'http://www.DOMAIN.com'; // NO trailing slash!

change to

# $base_url = 'http://www.DOMAIN.com'; // NO trailing slash!

freedom isn't free

trentharlem’s picture

Pascal.s commented 

I called the technical support for this and they changed a parameter in mod_security.
Told me it might not work for everyone but before spending hours searching, i think it's worth the call!

izus’s picture

izus commented 

subscribing
I tried all methods listed here and spent 6 hours on it without solving it.
in my case the problem is due to Firefox but not chromium or arora.
I disabled many Firefox extensions but nothing changed
I even tried hard coding solution but then another warning with taxonomy module appeared !!!
Just didn't understand the hole of it

Twitter: @ismaeil_

trentharlem’s picture

sabrawy commented 

Subscribe

trentharlem’s picture

darnzen commented 

I was having this problem and thought maybe it was related to the ahah callback not being able to find the form it was being called from. I added a 'module_load_include' in the global scope (not inside a function) for the include file that contained the form_alter function and it cleared up the issue.

This doesn't really make sense to me, as I'm just doing a hook_form_alter in the main module file, and from there I do a module_load_include and call a function in the include file to do the altering.

trentharlem’s picture

elcapitan82 commented 

This sounds interesting. Could you please describe the specifics of your fix in more detail?

trentharlem’s picture

msathesh commented 

@darzen, I am having the same issue on my host and I have tried with the settings.php solution but nothing is moving. Can you please post it here in detail?

Update: Found a solution. The real problem was my host related. See what my host (digitalpacific) said

the error was related to the fact that the POST length was too long. It has now been increased to 34M for your site.

So that solved the issue.. It took me a couple of hours searching forums and boards though.. May be helpful for someone in the future..

smira’s picture

smira commented 

^ that's it! thanks for this.

on my NGiNX webserver all i had to do is add

"client_max_body_size 32m;"

and the request went through.

thanks again!

trentharlem’s picture

mosys commented 

Same here. Thank you!

e: to make sure one finds it by googling the server error message:

[error] 14706#0: *26 client intended to send too large body: 2814437 bytes, client: 192.168.1.2, server: 192.168.1.1, request: "POST /filefield/ahah/document/field_pdf/0 HTTP/1.1", host: "192.168.1.1", referrer: "http://192.168.1.1/node/add/document"
trentharlem’s picture

the-drupalizer commented 

I've got this error after migration. The Fix was very simple. Try

chown -R www-data:www-data /drupal/install/dir/sites/[example.com | default]/files/
trentharlem’s picture

robyedlin commented 

Hey folks,

I had this error trying to upload files and stupidly realized I had logged out from another tab. If you are logged out and try to upload anything you will get this error.

trentharlem’s picture

wuyang commented 

Really interesting, I've got into the same problems with FF, but it's working on IE, Chrome, have not figured out the reason.

trentharlem’s picture

neillodwyer commented 

Hate to keep adding to a horribly long list of possibilities but it seems that installing the PECL upload extension solved the problem for me. Worth a try if you are stuck anyway.

Rick Pelletier’s picture

Rick Pelletier commented 

I know this is an old thread, so please bear with me.

The dreaded and mysterious "HTTP 0 Error" reared it's ugly head while working on a custom module in a FreeBSD-based test environment. File uploads were crashing and things quickly came to a halt. We checked all the usual suspects to no avail (PHP memory issues, weirdness from Devel, Filefield/Imagefield/CCK updates, etc.).

Then a pattern was noticed: This error occurred only when uploading PNG files. JPG's and GIF's uploaded cleanly and without fuss.

An investigation revealed that the version of GD bundled with the FreeBSD 8.x distribution of PHP 5 appears to have only partial support for the PNG file format. Predictably enough, when the PNG file upload was handed off to GD by Image Field for processing, things fell down and threw the "HTTP 0 Error" (as a fall-through, presumably).

The workaround was simple enough:

ImageMagick (non-X11 version) was installed on the test server, followed by the Image API module for Drupal. Switching the "Image Toolkit" setting to use ImageMagick instead of GD solved the problem completely and work resumed on the test server without further incident.

The production environment into which this custom module was eventually deployed is a fairly typical RHEL/CentOS installation as seen at fairly typical ISP's. The bundled version of GD available on that system had full PNG support and functioned as expected.

The moral of the story: Make sure you're aware of what version of GD your PHP 5 installation is using and what it's compiled-in capabilities are. If other measures have failed, changing image toolkits might be a worthwhile idea.

"It is good that you seek wisdom. But in the Way of Unix, there are no secrets."
--Master Foo and the MCSE

trentharlem’s picture

rcordes commented 

This worked.

trentharlem’s picture

giga-b commented 

I have an error on plesk panel
http://forum.parallels.com/showthread.php?t=112735
thanks to www.abserhosting.com/

asanchez75’s picture

asanchez75 commented 

When xxxx > yyyy (bytes) error appears. You need to change MaxRequestLen variable in your mod_fcgid.

[Mon Oct 17 22:02:41 2011] [warn] [client 190.235.214.249] mod_fcgid:
HTTP request length 135286 (so far) exceeds MaxRequestLen (131072),
referer: http://example.org/node/add/story
trentharlem’s picture

Romejoe commented 

Same here, was a problem with Opera, using IE made it work fine!

trentharlem’s picture

varuntaliyan commented 

After wasting couple of hours trying different solutions, it finally got resolved in my case by updating filefield module.

trentharlem’s picture

bmkaradia commented 

It is not problem with "jquery.form.js"

Filefield module replacement is the best solution of the problem.

trentharlem’s picture

wastrilith2k commented 

I am using nginx and I didn't have the following specified.

client_max_body_size 4M;
client_body_buffer_size 128k;

I set it to

client_max_body_size 20M;
client_body_buffer_size 128k;

and was able to upload without issue.

James

trentharlem’s picture

TheDan commented 

I had to delete the whole drupal install, uploaded the latest version of everything and it worked then.

trentharlem’s picture

Varex commented 

None of the suggestions above worked for me, I tried the commenting the ahah code from the filefield_widget.inc and it broke the images uploader, then I tried updating the filefield module and updating jquery.form.js file but nothing so far worked.
For me images bigger than 100kb shows the ahah error when trying to upload. I don't think the problem is with the server since I have another drupal site and it works fine, but this one is really weird and I spent too much time trying to fix it.

katzilla’s picture

katzilla commented 

After digging around for several hours (increasing the php memory_limit, the upload_max_filesize and post_max_size without any success...) I found this error-Message in my server-logs:
mod_fcgid: HTTP request length 132480 (so far) exceeds MaxRequestLen (131072)

I told the hosting company, they fixed it and now it works fine again. Sometimes (or likely in *all* cases) it helps to read the server error-logs ;-)

trentharlem’s picture

dvasquez commented 

Chrome is my problem. When i run my Drupal in FireFox all it's fine.

trentharlem’s picture

Studio FJ commented 

We have been dealing with the issue of FileField not allowing us to upload more than 1MB files and giving us a "HTTP error 0 occurred" message 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

ragavendra_bn’s picture

ragavendra_bn commented 

thanks, your solution worked right away ... (y) ....

nguyentran’s picture

nguyentran commented 

Hi, Try jquery update module. It worked. Or you can tryhttp://munkyonline.co.uk/articles/http-error-0-occurred. Goodluck. Hope this help someone. Thanks.

AdamEvertsson’s picture

AdamEvertsson commented 

Thanks to Pascal Roy's comment from 2011, I contacted my web hosting company to see if they had changed something recently since one image upload field (out of many) had stopped working and threw me ahah-errors. Since it was only one field that stopped working, I was puzzled, and my hosting company answered that they update mod_security every night and the error originated from there.

So, thanks Pascal, and to all you out there - get in touch with your web hosting company in an early stage to see if they have done something to mod_security.

// Adam

-----------------------------------------------------
www.adamevertsson.se - Blogging about Drupal...

trentharlem’s picture

cigotete commented 

according the sysadmin, seems that the cause of this error message has been related with the space on hard disk, so this could be a new cause.

I have reviewed this and other sources (https://drupal.org/node/434394,https://drupal.org/node/1061446) and I have extracted the following possible areas to be checked ((please seek for respective messages for further references)):

- increasing the php memory_limit, the upload_max_filesize and post_max_size
- review version of GD in front of your PHP 5
- review on NGiNX webserver client_max_body_size (https://drupal.org/node/659206#comment-5444846)
- disable browser extensions
- change mod_security parameter (is not given the parameterhttps://drupal.org/node/1061446)
- updating jquery.form.js on /misc or under jquery_update
- use/update jquery_update
- PECL upload extension
- check permissions and owners
- comment base_url line in settings.php
- Upgrading from filefield-6.x-3.7 to filefield-6.x-3.9 (or to upgrade to a newer version).
- version of CCK
- comment filefield_widget.inc '(#ahah' array)https://drupal.org/node/659206#comment-3001506
- space on hard disk
 

  •  
来自 https://www.drupal.org/node/659206