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.
Click Attach button to upload an image when creating content, there is a popup:
"An an http 0 occurred
upload/js"
I try to disable the "Clean URLs" opiton and then got no error.
rewrite conflict with js?
Comment | File | Size | Author |
---|---|---|---|
#110 | Acchi_Kocchi.jpg | 12.38 KB | haclong99 |
#59 | ajax_example_http_error_0.tgz | 4.06 KB | rfay |
#53 | 240777_jqForm.patch | 17.42 KB | andypost |
#48 | jquery.form_.js_.txt | 10.27 KB | andypost |
Comments
Comment #1
Setzler CreditAttribution: Setzler commentedI'm getting this, too. I think it might have to do with poorly written AJAX modules.
Comment #2
ztyx CreditAttribution: ztyx commentedI'm investigating whether this issue is the same as #279106: Upload Module Error 0?.
Comment #3
mot CreditAttribution: mot commentedIs this reproduceable with 6.5?
Comment #4
ortizmj12 CreditAttribution: ortizmj12 commentedI'm using Drupal 6.6, and I'm getting the same error. Except when I disabled clean URL's, I'm getting this error instead:
Comment #5
Setzler CreditAttribution: Setzler commentedReply with your htaccess rewrite rule. You might need to escape your dot.
\.
Because it could be interpretingupload.js
asupload/js
or vice versa since.
means "any character."Comment #6
ortizmj12 CreditAttribution: ortizmj12 commentedHere's the rewrite section I found in .htaccess:
**EDIT**
I just checked sites/default/files, and the file I was attempting to upload was uploaded successfully, yet I got the error... *confused*
Comment #7
Setzler CreditAttribution: Setzler commentedIf the file made it, then it probably didn't have anything to do with your rewrite rule, and most likely has everything to do with the module. Just a curiosity, but does changing the rule to
RewriteRule ^/(.*)$ index.php?q=$1 [L,QSA]
have any effect? If so, what?Comment #8
ortizmj12 CreditAttribution: ortizmj12 commentedI made the change, and I wasn't able to get beyond the Drupal frontpage. I have my Drupal install in a drupal directory like this: http://domain.com/drupal. Whenever I tried to access drupal/admin or drupal/node/add, it'd direct me to http://domain.com/index.php - some PHP stuff I was playing around with before installing Drupal.
Comment #9
fabius CreditAttribution: fabius commentedI am getting the same error with a file that is 1.25MB and larger than the max size. I expected GD or some other module to resize it to my set max of 640x480 (as advertised).
I tried with a file I resized first and there was no problem.
I have ImageField and another image-related module installed.
D6.6
Fabius
Comment #10
miurahr CreditAttribution: miurahr commentedI'm also getting the same error when I try to upload doc file which is as large as 1.38Mb.
I see html source, so I found follows;
This shows us actually "/upload/js" is inside the code.
Comment #11
tamatama CreditAttribution: tamatama commentedwhich ever browser you are working on your site from, you can swap to another one and attempt to reload the image.
I just started getting this error today in IE ver 6.0 and before I made a few changes, tried the same process from firefox and the image succesfully loaded
using drupal ver 6.6
let me kow
cheers
Comment #12
miurahr CreditAttribution: miurahr commentedIt workd fine with IE6 !
It is bad with firefox for drupal 6.8.
someone say IE7 is also bad(on anonymous bbs)
It is critical for users who use other than Windows. (Mac, Linux)
Does any reason?
Comment #13
miurahr CreditAttribution: miurahr commentedIt looks same as
http://drupal.org/node/226653
Comment #14
miurahr CreditAttribution: miurahr commentedI try to capture with firebug.
There are headers;
response is as follows;
Comment #15
jcfiala CreditAttribution: jcfiala commentedI had this happen on a site in development, and the culprit turned out to be the memcache admin code that would write memcache statistics at the end of each page. You might want to check if some module you have running is writing to the end of each page's output, because if so that will screw up the ahah.
Comment #16
miurahr CreditAttribution: miurahr commentedI confused.
It is not reproduced with Firefox 3.0.1 on Ubuntu GNU/Linux w/ direct connection.
Difference are proxy existence and Firefox 3.0.4 on Windows or Linux.
Comment #17
borat CreditAttribution: borat commentedAny updates on this?
Comment #18
spookypld CreditAttribution: spookypld commentedHi.
Hope this gonna help a bit.
I've this bug is going only when I'm using Opera bowser. Firefox 3.0.5 and IE6 is working fine. I don't know how it is going in WebKit core browsers.
In Firefox I can 'make' this bug happen by trying to upload unallowed file (by extension).
Eventually I'm using PathAuto.
Comment #19
nicorac CreditAttribution: nicorac commentedJust my 2 cents, I have the same problem on Drupal 6.9:
on remotely hosted site:
IE6 on XP-SP3 --> error
FF 3.0.5 on XP-SP3 --> error
FF 3.0.5 on Ubuntu 8.10 --> error
Clean URLs off --> error
updating jquery.js and jquery.form.js --> error + browser lock
deleting jquery.js and jquery.form.js --> OK (but no AJAX at all)
local site (XAMPP 1.7.0): everything works OK
Comment #20
wes_elder CreditAttribution: wes_elder commentedHey, Maybe this is a clue...
warning: Invalid argument supplied for foreach() in /var/www/html/drupal/sites/all/modules/filefield/filefield_field.inc on line 127.
Comment #21
sullo CreditAttribution: sullo commentedThis may be a memory issue. I had this error with Image Browser. I tried it again and the page did not load, the php log said it was out of memory. I upped the memory_limit from 32 to 64mb and retried, and the Image Browser module worked. This time, however, it uploaded the image *and* the image with the "http 0" upload was there.
Hope that helps.
Comment #22
brendoncrawford CreditAttribution: brendoncrawford commentedsubscribing
Comment #23
btopro CreditAttribution: btopro commentedI get something similar to this with AHAH stuff where it will commit the action yet return an error message.
Comment #24
wes_elder CreditAttribution: wes_elder commentedTo update my situation (noted in posting # 20). PHP was completely out of memory. The solutions I used to resolve it is noted here:
http://drupal.org/node/207036
Comment #25
zila CreditAttribution: zila commentedOops! In devel module by disabling 'Display whatever' options, the problem is eliminated. So I think this is a devel.module issue...
Thanks @jcfiala!
Comment #26
yakupaltas CreditAttribution: yakupaltas commentedsimple
look apache configuration = sites_enabled
"alias /upload/"
rename alias /uploads/ or etc..
no problem.
Comment #27
gamer24 CreditAttribution: gamer24 commentedOk, tested on 6.10 and so far only Opera is giving the problems with the uploads with the same error. IE7 and Google Chrome work perfectly fine. Any more updates on what could be causing this?
Comment #28
Blue CreditAttribution: Blue commentedI confirm that this not works on OPERA !!! In firefox works great !
I also get the "An HTTP error 0 occurred." but only when i use opera. Can this be fixed?
DRUPAL TEAM:
Also if i try to attach a file here in DRUPAL.ORG i get this error - "An HTTP error 0 occurred. /comment-upload/js" .
I used Opera browser. Seems like is a conflict somewhere.
Comment #29
did1979 CreditAttribution: did1979 commentedHello,
I have the same problem but with all browser.
I've tried all exposed solutions, but I do not found why I have the upload error.
Does anyone have an idea ?
I've tried to modify the memory limit of php.ini. I've modified the upload size. Uploads works with small files or images but bigger than 1 Mo I become the Upload error "An HTTP error 0 occurred. /drupal/upload/js" .
I've tried to install modules JQUERY FORM UPDATE (with JSALTER module) but the problem still occured.
I've tried to remove pathauto or Clean Urloption, but nothing happens.
What can I do ?...
thanks.
Did
Comment #30
fivehimself CreditAttribution: fivehimself commentedProblem also occured on my production server, no problemo on localhost MacBook.
From my Apache error log, I grabbed the following error:
The path to my sites directory is C:/inetpub/wwwroot/aqua-sandbox/sites, and not C:/inetpub/wwwroot/sites.
I'm using the File Framework module, with Attach and Bitcache. The files are stored inside the Bitcache repository, but something is going wrong and produces the:
"An HTTP 0 error occurred.
/aqua-sandbox/file_attach/js"
I've increased memory up to the point of 128M, but that doens't seem to be the problem...
[EDIT] Disabled all modules, and activated them one at the time. This worked for me: http://drupal.org/node/483098
Comment #31
postrational CreditAttribution: postrational commentedStill fails in Opera. Works fine in Firefox and Safari. Tested on a Mac.
Comment #32
jmpalomar CreditAttribution: jmpalomar commentedSubscribe.
Comment #33
tyr CreditAttribution: tyr commentedI had got the same problem only with Opera.
Seems to be either an Opera or jquery.forms.js bug, I'm not sure.
Updating jquery.forms.js to version 2.18 (with drupal comes 2.01) solved the problem for me (as described here: http://drupal.org/node/226653#comment-840590)
The funny thing is, that version 2.28 of jquery.forms.js (from malsup.com/jquery/form which is a few months younger than 2.18) fails again with the very same HTTP Error 0.
The hack that fixes the problem in 2.18 is not present in 2.28 anymore. However, these are the essential two lines of the hack:
Comment #34
drubage CreditAttribution: drubage commentedI have this problem in all browsers. I am trying to use the node gallery module which allows you to upload several pictures at the same time. It is then supposed to show a preview page where you can enter a title and caption for each pic (and choose a gallery cover). If you submit this page it will then finally commit the nodes. So what happens is that the file uploads correctly into first the tmp directory then properly moves to the final directory. Then Drupal inserts a row for each picture into the "files" table. BUT, at this point I get the error 0 and nothing is ever written to the node table.
It used to work but stopped all of the sudden once we made the site live (of course). I upped the php memory to huge amounts and tried replacing the .js file as people have suggested.
HELP!
Comment #35
ac00perw CreditAttribution: ac00perw commentedI get this error too- both on my personal site and on api.drupal.org (top left search box) if I hit submit before the autocomplete processes. Granted most of my users won't be smacking the submit button as fast as the results display, but regardless it would be nice to at least suppress the error.
Anybody?
Comment #36
christophhesse CreditAttribution: christophhesse commentedI get this error with the views 2.6 module. When I remove the module, the error is gone.
Reenable the module --> Error is back.
IE 6 and FF3.5 (newest Firefox, so this is not an issue with outdated browsers!!) - upload of some files, not all - maybe a memory issue for resizing the images in combination with views?
Even with the newest jquery.form.js I get the error. Cache has been cleared (with devel)
Anyone has had a similar combination views + upload --> Error 0 upload/js?
Comment #37
jottmalzwo CreditAttribution: jottmalzwo commenteda few days ago I got the same error warning, no matter what browser i used (drupal 6.13 and ff 3.5 without any add-ons, safari 4, opera ..). then i found out that the problem only occured when the "split summary at cursor"-option was used. after putting the text together the upload-modul worked fine again.
hi drupal-team, looks like there's a little bug in the code ...
greetz
jürgen
Comment #38
ferdo CreditAttribution: ferdo commentedLinux, Drupal 6.13,
Firefox 3.5.2 -> An HTTP error 0 occurred. /index.php?q=upload/js
Konqueror 4.3.00 -> work OK
Arora 0.9.0 -> work OK
Comment #39
misterlawrence CreditAttribution: misterlawrence commentedsubscribing
Comment #40
dcumbo CreditAttribution: dcumbo commentedsubscribe
Comment #41
WebNewCastle CreditAttribution: WebNewCastle commentedI've encountered this error in different places and situations - one being with auto complete on a free tag taxonomy field (and previously with some file fields). In case any of the issues listed here are similar to what I've seen, this is what I found.
The most recent HTTP 0 error I experienced came after I changed the htaccess file settings to redirect users to the URL with the "www". The HTTP 0 error I saw, which included the auto complete URL in the second line showed the URL didn't include the "www". Hence, the HTTP 0 made sense to me.
So, what I found is that in this particular case, I had specified the Base URL in my settings.php file (I usually don't) - and the URL specified didn't include the "www". So both changing the URL to include the "www" and just commenting it out solved the problem - because it eliminated the conflict with the URLs on the page and the form.
Comment #42
ghiotion CreditAttribution: ghiotion commentedIt took me a couple of hours to figure out what was going on with my installation and I figured I'd post here in case anyone else encounters my specific issue. I had an outlier case in that the file was correctly making it to my Web server's file system, but I was still getting this error. I tried swapping out the jquery.js and jquery.forms.js file to no avail. Finally, after some intense debugging with firebug, I noticed that jquery.forms.js was throwing an exception in the top most html tag section.
Specifically in the xmlns:foaf piece. Some strange exception about "gt is not defined". One of my developers (a week and a half ago) had installed the RDF module (RDF 6.x-1.0-alpha7) to clean up drupal's rss feeds and that was adding dc, foaf, and rdf pieces to the doc spec. Once I uninstalled the RDF module, everything worked again.
Hope this helps someone. I know it would have saved me about 4 hours.
Comment #43
noisephoenix CreditAttribution: noisephoenix commentedthis is driving me crazy too. when I press "upload" I get the HTTP error 0, but if i just save then everything works fine.
have tried replacing jquery.form.js, playing with permissions, changing php memory, nothing get's rid of the error message :(
Comment #44
meramo CreditAttribution: meramo commentedSame problem with 6.14. No luck to solve it via one of many methods proposed. It really pisses me off :(
Comment #45
donquixote CreditAttribution: donquixote commentedThere is some interesting info in this thread,
#434394-110: 'HTTP error 0 occurred' on image upload and further down.
Apparently there are two unrelated problems, that just have some similar symptoms:
a) problems with memory_limit on shared hosting
b) a quite obvious bug in jquery.form.js. The problem here is that the iframe onload event fires for an empty iframe.
Comment #46
andypostConfirm hat bug related to jquery.form.js and reproducible under opera 10 with any drupal 6 install
bad news that d6 branch is frozen and it needs to test a large set of contrib modules which is working with this library
Comment #47
donquixote CreditAttribution: donquixote commentedCould this be fixed with a contrib javascript?
All it needs to do is either replace the core jquery.form.js (though I don't know how that works), or manipulate the $.fn.ajaxSubmit() function declared by core jquery.form.js.
Comment #48
andypostSame bug with D7 branch, so moving here!
When I replace jquery.form.js with attached 2.28 version and it works, suppose it needs more testing and maybe newer version from http://jquery.malsup.com/form/
Comment #49
te-brian CreditAttribution: te-brian commentedI am working with the latest Drupal 7 HEAD.
I had the same experience as andypost. I was getting the dreaded "http 0" message in a form that uses a 'managed_file' element. My case is a little special, because I am overwriting the default ['#ajax']['path'] with my own ['#ajax']['callback'], but I got the error none-the-less.
Updating to the latest form.jquery.js from malsup's site (the file is commented as being updated on 11/9/09) "fixed" the problem. I always hate when I don't understand why something works or doesn't work but in this case grabbing the latest version was the quick fix.
So +1 for updating to the latest incarnation.
Not sure how to roll a patch that replaces a file.. so someone else will have to help with that.
Comment #50
mistermarco CreditAttribution: mistermarco commentedOriginally, for historical reasons, we had set up our Drupal instance to use a directory at root called "upload".
Once we changed our instance to use the default of "/sites/default/files" and deleted that "upload" directory the error went away.
We were using 6.13.
Comment #51
devkinetic CreditAttribution: devkinetic commentedI'm getting the same error, but oddly it's only on ONE of our machines running safari 4.0.3. Using the same account, I can upload on my machine, my managers, but not our content managers.
We all have the same systems with the same builds of safari. The error we are getting is:
An HTTP error 0 occurred.
/upload/js
I tried resetting her safari but it was a no-go. Any idea's
Comment #52
andypostThis should be fixed in HEAD first
Comment #53
andypostPatch against HEAD (file from #48)
Comment #54
te-brian CreditAttribution: te-brian commentedMight as well use the latest version. Was released on Nov. 7 2009. http://jquery.malsup.com/form/jquery.form.js?2.36
Comment #55
andypost@te-brian do you test this version with file/image upload?
2.28 works fine but 2.35 dont
Comment #56
te-brian CreditAttribution: te-brian commented@andypost - I cannot say I have done extensive testing by any means, but I am using a few 'managed_file' FAPI types and they work fine. File and Image modules use the 'managed_file' so should work also, but you know what they say about assumptions.
Comment #57
Dries CreditAttribution: Dries commentedI agree that we should try to upgrade to the latest version instead.
Comment #58
donquixote CreditAttribution: donquixote commented@andypost (#55):
I tried with 2.36, and this worked (but not 2.28).
Unfortunately I can't download older versions. No matter how I hack the parameter of the URL, I always get 2.36.
The problem in the 2.28 version is explained here:
#434394-113: 'HTTP error 0 occurred' on image upload
It would be interesting to see how the newer versions attempt to fix this.
Comment #59
rfayMaybe we're working on different errors, but the attached module demonstrates this happening with #53 deployed.
I'm actually working on #634628: AJAX "HTTP Error 0" when AJAX operation is interrupted., which I hoped was related.
To demonstrate the error using the attached module
1. Untar the module.
2. Enable "Ajax Example" module.
3. Go to the "Checkboxes example" page. A menu is provided. (ajax_example/autocheckboxes)
4. Change the select, which triggers an ajax callback. The ajax callback has a 2-second sleep in it.
5. Within 2 second, press the submit button.
This demonstrates the slow-response HTTP error 0. And it demonstrates it with #53 as well.
Comment #60
rfayIt turns out that the sort-of-documented behavior that gets an "HTTP Error 0" is firefox 3+ having an XMLHTTPRequest get aborted or interrupted - see http://drupal.org/node/634628#comment-2319776.
So in this issue what I see is that the *AJAX callback* might be failing in various ways. Out-of-memory is one of those.
Can someone set up a definitive test case that demonstrates this one? I suspect that every case in which
1. the AJAX callback is aborted with javascript abort() or
2. The AJAX callback fails or returns invalid JSON (basically the same thing)
will result in HTTP Error 0 on Firefox 3+.
Comment #61
rfayOne of the key things we can do about this is to change so that we get decent information when the HTTP Error 0 occurs. The patch in #646694: AJAX: Terrible reporting of status 0 response from AJAX request ("HTTP Error 0 has occurred") does that. It reports all of the available information about the XmlHTTPRequest object that is passed as "result".
I ask everybody watching this issue to do 2 things:
1. Review #646694: AJAX: Terrible reporting of status 0 response from AJAX request ("HTTP Error 0 has occurred") and set it to RTBC if it is.
2. Install the patch at #646694: AJAX: Terrible reporting of status 0 response from AJAX request ("HTTP Error 0 has occurred") and re-create the error you're having. Post the exact steps and environment to reproduce, along with the exact text in the new dialog box that comes up after this patch is installed.
Thanks,
-Randy
Comment #62
yched CreditAttribution: yched commented@rfay: did you really intend to link to the same issue twice ?
Comment #63
rfay@yched: I guess I'm asking people to review the other issue so we can get it in.
I'm *also* asking to install it on their installation until it lands so that they can describe more completely what happens.
IMO we can solve more of these if we can get this patch in, and I'd like to start getting information even before the patch lands.
Comment #64
Aleksic CreditAttribution: Aleksic commentedThanks, it`s work for me:)
Comment #65
wxman CreditAttribution: wxman commentedI too have been fighting with this same problem while testing out Node Gallery, but I'm on Drupal 6.x. FF, IE7, and Chrome, all work fine, but the error occurs only on Opera10. I replaced the Drupal jquery.form.js with the 2.36 version at the link in #48, and now it all works great.
Comment #66
RobLoachHere you go, gents: #609622: Keep jQuery Form up to date . Let's keep issues on track.
Comment #67
rfaySo the latest JQuery form got committed on January 18. Please check to see whether this issue can be marked fixed.
Comment #68
drupal92037 CreditAttribution: drupal92037 commentedThe fix in #48 did not work for me.
(Actually, it didn't work for one of my users. I could never reproduce the problem in the first place).
Comment #69
ikeigenwijs CreditAttribution: ikeigenwijs commentedSame problem: upload file, upload gets done but error http 0 appears.
using
core upload module on page rights ok.
drupal 6.15
firefox 3.6
read a lot of posts, but noting helped
greetings
Comment #70
Aleksic CreditAttribution: Aleksic commenteddrupal92037 did you try #53
Comment #71
rfayLet's not change the Drupal version until we can confirm that this is fixed in D7.
If this is completely due to Ajax Form being out of date, it may or may not get fixed in D6. But it probably would be fixed.
Note that in D7 the error dialog will be different now, with more information. I'm betting it's fixed, but there have been no reports of that.
Comment #72
naught101 CreditAttribution: naught101 commentedsubscribe
Comment #73
arhak CreditAttribution: arhak commentedrelated to #646694: AJAX: Terrible reporting of status 0 response from AJAX request ("HTTP Error 0 has occurred")
(that issue only cares about the ugly message, which was improved)
Comment #74
gumrol CreditAttribution: gumrol commentedThanks ghiotion! I have the exact same issue.. except I need RDF installed...
I suspected RDF, but you confirmed it for me. Thanks for the post.
Comment #75
mansspams CreditAttribution: mansspams commented#53 did not help with this error in Chrome (taxonomy/autocomplete/7)
Comment #76
srobert72 CreditAttribution: srobert72 commentedSubscribing
Comment #77
naught101 CreditAttribution: naught101 commentedIn drupal 6, I updated both jquery.js and jquery.form.js to the latest version. Didn't fix the problem (which appears to only be happening in firefox on windows, for one of my clients).
Comment #78
rfay@naught101: See #60. The "Error 0" is AFAICT a firefox 3+ only behavior, because somebody at firefox decided to start returning 0 when the HTTP status code was supposed to be returned.
That doesn't deal with what's causing the error, but in many of these cases, it's not even an error. If I understand this issue correctly, this is an actual misbehavior (attach fails) but in many of these that's not the case. I'm hoping in D8 we could do #727278: Add watchdog interface for javascript code to use.
Comment #79
srobert72 CreditAttribution: srobert72 commentedI have last version of "devel module" 6.x-1.x-dev (2010-Feb-14).
Disabling it solves my problem.
Comment #80
ash_choice23 CreditAttribution: ash_choice23 commentedJust change your browser, if you are using any other to Mozilla Firefox. It works just fine with it.
It shows no error then and the file gets attached.
Comment #81
rfay@ash_choice23: We support a wide variety of browsers and don't limit Drupal users to just firefox.
I might add that the "HTTP Error 0" variety of failure occurs *only* on firefox and variants of it.
Comment #82
calber CreditAttribution: calber commentedsubscribing
Comment #83
morphet CreditAttribution: morphet commentedNone of the fixes above worked for me. I'm on Godaddy shared hosting and cannot restart Apache.
XP: Firefox, IE
Linux: Firefox, Chrome, Opera.
None work. Turning javascript off while you do the upload does let me work around the problem.
Comment #84
rfayUntil this is confirmed fixed on 7.x, please do not change the version number.
Comment #85
donquixote CreditAttribution: donquixote commentedWe have more of this kind, with different modules, and with different causes. I think tagging is a good idea to get an overview.
EDIT:
Damn, it's not. Clicking the tag only gets you to the page with all issues for this one module.
Here is the general overview page, but you don't get there by clicking the tag:
http://drupal.org/project/issues/search?issue_tags=ajax%20upload%20problem
Comment #86
ib CreditAttribution: ib commentedI'm having D6.16, and the problem is the same as mentioned at the start of the topic.
I tried module disabling and re-enabling, as well as the the jquery.forms update.
Currently I feel it is a problem with the theme, since for me it works great under Bluemarine, but not under my preferred (custom) theme (Fourseasons).
(And with IE6 it was also okay, independently of the theme.)
Comment #87
eshbaugh CreditAttribution: eshbaugh commentedI just had this issue with the popup:"An an http 0 occurred upload/js" on our new web server, but only with larger files.
Increasing the post_max_size php.ini setting to a value larger than the file I was trying to upload resolved the issue.
Here is the section changed from my php.ini file:
upload_max_filesize = 100M
post_max_size = 100M
Make sure to restart your httpd service after saving the php.ini file:
/sbin/service httpd restart
Hope this helps.
Comment #88
Peter Arius CreditAttribution: Peter Arius commentedI'm having the same issue with:
D6.16
(concerning #79: Devel module not enabled)
Download method: private
Vanilla Firefox 3.6.3 (even with all extensions and plugins disabled), but NOT with IE8
Windows XP SP 3
What's happening exactly:
File size is not the problem: error occurs even with tiny files.
Updating jquery.js to 1.4.2 and jquery.form.js to 2.43 does not help. The behaviour (point of time, when the error is displayed, ...) is slightly different, but basically the same error happens.
Found two workarounds so far:
HTH,
Peter
Comment #89
kunago CreditAttribution: kunago commentedI too did suffer from this issue. It seems to be dependent on the browser used.
In order to update a little bit those who suffered while using Opera, I am running Opera 10.53 and the issue no longer occurs.
Few weeks before, I also had similar issues with Firefox. It was discovered later on that some user scripts and Greasemonkey were to blame for the issue.
Comment #90
BCM CreditAttribution: BCM commentedsubscribe
Comment #91
sblommers CreditAttribution: sblommers commentedOk,
I have this same issue but I know that I did this myself. I am trying to reuse autocomplete list from node-reference, user-reference. Therefore I get the wrong json (the results are not real JSON, thus failing on jQuery). I don't completely understand why drupal is working with faulty JSON formats, this will be a major issue on interoperatbility (for example in my scenerio where i reuse autocomplete through drupal).
Back ontopic.
I edited common.inc (line:2445) (remember I'm using drupal 6.16)
case 'string':
// @CHANGED TO FIX REMOVE AUTOCOMPLETE WITH DRUPAL
// return '"'. str_replace(array("\r", "\n", "<", ">", "&"),
// array('\r', '\n', '\x3c', '\x3e', '\x26'),
// addslashes($var)) .'"';
return '"'. str_replace(array("\r", "\n", "<", ">", "&"),
array('\r', '\n', '\u003c', '\u003e', '\u0026'),
str_replace("\'","'", addslashes($var))) .'"';
Now on the server I get the error that you guys have. After changing this code back upload module works BUT check out drupal_urlencode in common inc (2510) where a check for clean_url is used. There might be something wrong there. For now I fixed my problem but there is still another issue for me to solve for the autocomplete functionality. I hope I make a little sense here and I hope this issue is resolved quickly.
Comment #92
arhak CreditAttribution: arhak commented@#91 #479368: D7: Create RFC compliant HTML safe JSON
Comment #93
RgnYLDZ CreditAttribution: RgnYLDZ commentedGot the same problem. I can't upload anything in any module or any content. Everything is 777 in my folders.
Safe Mode issue ?
Comment #94
rfay@eyildiz: If you're working with D7, then you got a far more significant error message, so please make sure to post it.
Comment #95
hurricane66 CreditAttribution: hurricane66 commentedFor us the #25 was the solution. Unchecked "Display page timer" in /admin/settings/devel (the other "Display"-options were already unchecked in our case) and upload works fine again not showing the "An HTTP error 0 occurred" "/upload/js" error message.
Comment #96
ikeigenwijs CreditAttribution: ikeigenwijs commentedFor me too
i only have it when adding an file as attachment in organic groups.
There are numerous files added without any problems, it s about a small docx file 35kb
we used not the devel page timer but the memory usage
Comment #97
ausber CreditAttribution: ausber commentedYou just have to update the jquery form plugin : http://drupal.org/project/jquery_form_update and download the jsalter module as well to make it work...
Comment #98
janwalhof CreditAttribution: janwalhof commentedOnly unchecked "Display page timer" in /admin/settings/devel and the problem was solved!
Thanks,
See also for multiple attachments: http://drupal.org/node/825032
Everything is fine now.
Regards,
jan Walhof
Comment #99
rfay#98: Everybody should note that *all* AHAH/AJAX operations are broken if extra data is emitted on a page beyond the drupal page. This is because AHAH is a callback to the server, and if something like the devel page timer is output with the AHAH JSON data, it all looks like garbage to the client and is discarded.
The other common situation where this happens is debugging code that is writing directly to the page.
Comment #100
bryancasler CreditAttribution: bryancasler commented#97 seems to have worked for me.
Comment #101
maceo CreditAttribution: maceo commenteduninstall devel module worked for me!
disabling it alone does not work.
Comment #102
kriskhaira CreditAttribution: kriskhaira commentedI strongly recommend that everyone having this problem try downgrading to PHP 5.2. There seems to be a popular mistaken belief that Drupal has been supporting PHP 5.3 since version 6.14. The Drupal system requirements page states that Drupal core supports PHP 5.3; emphasis on "core". Many contrib modules do not support PHP 5.3 yet.
I tried the following, but none of them worked except for downgrading to PHP 5.2.
Comment #103
potsed CreditAttribution: potsed commentedDowngrade did not work for me.. This is very frustrating as is drupal in general from a developer point of view. I am only using it because the client wanted it.
Comment #104
aleksey.tk CreditAttribution: aleksey.tk commentedThis error usually happens when AJAX request is interrupted by user interaction, like when Views module automatically generates preview and it takes too long and you press save. Actually i understand why increasing php memory, cleaning caches and other random stuff helps people avoid this - AJAX requests just works faster and it is almost not possible to interrupt it manually.
Comment #105
2dareis2do CreditAttribution: 2dareis2do commentedWorked for me. Thx
Comment #106
sheba CreditAttribution: sheba commentedSolved.
My problem caused scaling upon upload that exceeded memory limit of script.
So, i changed sites/all/default/settings.php and added this code: "ini_set('memory_limit', '256M');" in "PHP settings:" section.
Hope, this helps.
Comment #107
lily.yan CreditAttribution: lily.yan commentedI got "An HTTP error 0 occurred" when I am trying to use autocomplete list from node-reference.
My website is set as whole security website (https). When my development site is non-security (http), autocomplete list from node-reference works fine.
How to make it work under https?
Thanks a lot
Comment #108
rfay@lilyyan, you're discussing the problem in #863562: Change $base_url to https:// if explicitly set to http:// by settings.php, and it's really a function of how securepages works.
Comment #109
lily.yan CreditAttribution: lily.yan commentedThank you so much, rfay
I fixed this problem by changing $base_url from 'http:' to 'https:' in settings.php.
Comment #110
haclong99 CreditAttribution: haclong99 commentedI've got the same error
I'm using
- Drupal 6.19
- no contributed module
- no extra theme installed
- Upload module enabled
- RewriteBase set in my .htaccess (RewriteBase /my_drupal_site)
- settings.php updated ($base_url = 'http://subdomain.domain.com/my_drupal_site')
- php maximum file size per upload = 50 Mo
My maximum file size per upload in admin/settings/uploads is 50Mo also
I try to upload a 13ko file
I have been testing on
Mozilla Firefox 3.5.9 on Windows XP SP3 -> i've got the error
Mozilla Firefox 3.6 on Ubuntu Lucid -> i've got the error
IE 7.0 on Windows XP SP3 -> i've got the error
On the same Mozilla FF 3.5.9 on Windows XP SP3,
I try to upload an image on drupal.org/node/16715 -> error when trying to upload the image in comment
I try to upload an image on drupal.org/comment/reply/240777 -> looks like it works
I try to upload an image on groups.drupal.org/user/XXX/edit -> it works !!!
I have tried
- update jQuery form -> ko
- change the upload file size limit
I don't know what to do
How can i try with the patch rfay did for D7 ?
**edit**
Looks like my uploaded image works... now i can't delete it... so i'm very sorry because this has nothing to do with the node nor drupal... this was only an image i'm using for testing... i didn't expect it to work actually.
Comment #111
haclong99 CreditAttribution: haclong99 commentedFor my part, i have to comment lines within the .htaccess in the /files directory.
I know this is not a secure behaviour and this worries me but this is the only thing i do to make upload works
Here is the content of my .htaccess:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
IndexOptions None
# Options +FollowSymLinks
My host is Online.net (Proxad). I believe they have special config for their Apache.
In their online documentation, there's no need to add "Options +FollowSymLinks" -> this generates an 500 error.
They recommend to use IndexOptions instead of Options... Hopes both are working alike...
Note : I apply the very same modification in the .htaccess on my drupal root directory.
**edit**
nope... these changes in my .htaccess numerous files are not enough... still get the error but now, the images are uploaded and displayed fine... just the error message which is confusing when uploading.
I can live with this but my website targets end-users and they won't be confident with this error.
Comment #112
pogonaV CreditAttribution: pogonaV commentedLooks like there is no simple answer to this issue.
One more piece of info to add. A colleague just ran into this issue for the first time. Ended up by working in IE, but repeatedly failing in Firefox (3.5.2). A check of the logs from when the error was first seen shows this message:
"More than one module has defined the node-url token."
For what it's worth.
Comment #113
rfayThe majority of these HTTP Error 0 errors occur when something adds to the page HTML (which is really returned JSON) an error message, or other irrelevant garbage. So what happens is that the AHAH callback does its thing, provides some HTML wrapped in JSON, and then something (maybe devel module, maybe anything that writes to the screen) adds something else to the page output. That makes the parsing of the JSON fail, and voila, HTTP Error 0. There are other cases.
But it's relatively likely that token module is writing to the screen in this case or something. You might look for that string in your code and see if it somehow gets written to the screen with a print statement.
Comment #114
donquixote CreditAttribution: donquixote commentedSo, what if we put these ajax callbacks in ob_start() and ob_get_clean() ?
And of course, we must absolutely avoid any access checking and wildcard loading for ajax/json callbacks through the menu router system, and instead do all this in the page callback itself.
I'm not sure atm which page callback this would be - do you?
EDIT:
For filefield, I found
- filefield/progress/[funky noise]
- filefield/ahah/[node type]/[field name]/0 (POST)
- a few images, which do not matter for us
Associated router paths declared in filefield_menu():
- filefield/ahah/%/%/% -> filefield_js(), filefield_edit_access()
- filefield/progress -> filefield_progress(), user_access('access content')
I strongly recommend we set access callback for these items to TRUE, and do the checking in the page callback instead. And in addition, do the ob_start() and ob_get_clean() and output this stuff in an alert() or something, or send it to watchdog.
If we were not living in a Drupal world, I would, in addition, wrap the stuff in try/catch.
And the %/%/% should probably be dropped altogether, so we have a route of filefield/ahah instead. The arguments can be checked in the page callback instead.
EDIT:
Yeah, filefield, I'm in the wrong issue.
So ok, next post I have a look how the upload module does it.
EDIT:
Filefield discussion goes here: #960048: Filefield: Wrap ajax callbacks in ob_start() / ob_get_clean()
Comment #115
donquixote CreditAttribution: donquixote commentedAjax callbacks in upload module:
- upload/js -> upload_js(), user_access('upload files')
Same recommendations as in #114 above.
Comment #116
jan.koprowski CreditAttribution: jan.koprowski commentedHi,
I believe this issue is hard to resolve because we have one error message for many different problems.
This also cause many different solutions. I also get one.
1) Many helpful was Google Chrome JavaScript console which return me Server error message which was:
the server responded with a status of 413 (Request Entity Too Large)
2) This follow me this is server issue (I use nginx php5-fpm) but before that I also increase:
3) I check this 413 error message for my HTTP server and found topic describing my issue for Nginx. This lead me to increase:
client_max_body_size 4M;
.So in my case this was Nginx issue not Drupal issue but strange thing is this is Drupal bug track :)
I believe the most of reasons is environment issues (like mine) not Drupal issue. I can't explain why sometimes browser can upload file but it looks like some of them can detect issues with file upload and handle this situation somehow e.g. uploading file in parts.
So I believe the goal of this issue should be gather all possible reasons and update documentation to pretend from this situations.
Comment #117
Neovirtua CreditAttribution: Neovirtua commentedI dont get this error, it all works fine, and was working fine for a client who I created a user for, but somehow, thye jsut started getting this error tonight, it's still fine for me, in IE, FF, Chrome and Opera, but for them, nothing, they get the error no matter what.
This is indeed strange, I have also logged in with the user account I created for them, and that also works for me, so its only restricted to them, not the server or anything else I can find!
bizarre, but if anyone knows a work around, I'd love to know
thanks in advance
N
Comment #118
gary.evans CreditAttribution: gary.evans commentedThe cache might be corrupt. Try Clearing the cache, this worked for me. (Also, I was using file minimization)
Comment #119
dark_love CreditAttribution: dark_love commented#53: 240777_jqForm.patch queued for re-testing.
Comment #121
Canadaka CreditAttribution: Canadaka commentedI started getting this error today trying to attach files to a 'page' node. I can upload files using CCK just fine, but not with the "upload" module.
The Chrome JS console outputs this when the message pops up: "Failed to load resource: the server responded with a status of 404 (Not Found)".
I've flushed the caches, including boost. Changes boost to only output to header, not that boost is caching the page since i'm logged in as admin. Tried 3 different browsers, my php limits are all set high.
Comment #122
rfay@Canadaka, do you get the problem with Firefox? If you do, you can use firebug (or a related http request watcher) Watch the HTTP requests. I think you'll see a 404, which means that the back-end URL that the AJAX request is trying to hit isn't actually configured. And yes, I would turn off boost for debugging.
Comment #123
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 #124
Canadaka CreditAttribution: Canadaka commentedI found what was causing my problem, it was a conflict with another module "fast_404". I don't know why tis causing this problem, for now I justed removed ".js" from the list.
$conf['fast_404_exts'] = '/.(txt|png|gif|jpe?g|css|ico|swf|flv|cgi|bat|pl|dll|exe|asp)$/i';
Comment #125
droshani CreditAttribution: droshani commentedI have the same problem.
I just changed my hosting service to a Windows VSP which allow me to eun both PHP and ASP.net. My site did not have this issue on previous Linux hosting with Apache, now I get this repost message in this relation
Upload progress Not enabled
Your server is not capable of displaying file upload progress. File upload progress requires PHP 5.2 and an Apache server.
also get error when I try to upload
An HTTP error 0 occurred\n/cms/upload/js
which should rather be
An HTTP error 0 occurred\n/cms/upload.js
I have PHP 5.2.13 but no Apache, Do you think this might be the cause?
Comment #126
yazzz.b CreditAttribution: yazzz.b commentedI don't get the error at all when using Windows XP (any browser), only on Windows 7. I have Windows 7 Ultimate 64 (don't know if that matters at all).
On my Windows 7 machine only Firefox 3.6 works. Also tested on Opera 11.0, Opera 11.1beta, and IE 8 and all of them get the same error.
I get the error not only when uploading photos but also when trying to add another item in a text field.
Another weird thing is that sometimes, maybe once every fifteen times, both uploading images and adding another text field item will actually work.
Comment #127
nomad-drupal CreditAttribution: nomad-drupal commentedAfter spending several hours chasing the "upload/js" ghost, comment #37 solved my "an HTTP "error 0 occurred" occurrence in drupal.
Removing the bar that separates the intro and body made the next file attachment possible again.
I had the problem before but couldn't remember how i solved it.
It started after I inserted the separator bar in the text just a few minutes after I uploaded a file successfully. First impression was a disk quota issue but it wasn't - enough disk space was available to store the next small file upload.
I got the "an HTTP "error 0 occurred" with Drupal looking for "upload/js" causing a 403 error because this location doesn't exist. In Google Chrome the java script console pointed me at the 403 (forbidden) error.
Good Luck!
Comment #128
rfsbsbToday this error has happened with a Drupal site I maintain. It's a Drupal 6.22 with some few contrib modules running on a Linux system at Linode.com.
I ended up discovering that the problem wasn't related to Drupal itself, but to my network.
Explaining my debug process:
I've logged at my linode through ssh and did a "tail -f mysite.access.log" to check if my request on uploading a file was reaching the server.
I've tried to upload (clicking on Attach button) many different files unsuccessful. I've checked my log file and nothing have happened there.
Then I've tried again, but this time clicking on Save button. It has redirected me to a error page, but not Drupal one. I've been redirected to the error page of the transparent proxy of my network.
After that I've concluded the problem, in my case at least, is related on how the proxy server is configured. With the proxy down, I've tried again the upload and it succeed!
Unfortunately it wasn't me who configured the proxy, so I don't know how to solve it.
I hope it help someone, at least as a clue on what to search for!
Comment #129
ponticlaro CreditAttribution: ponticlaro commentedI looked at a ton of forum posts around this issue. Lots recommended various things, but nothing fixed my issue.
Here is what fixed my issue, in case it helps you:
Try to take a look at the "page" that is shown in the error. In your case it is "/filefield/ahah/video/field_video/0"
and in my case it was "/poll/1"
Mine was a JSON document, but inside the document I could see a PHP warning and some garbled text with question marks (characters that could not be displayed). The first thing to do here, so that the JSON can validate is turn off PHP warnings. You can do this by placing:
error_reporting(0);
at the top of your /sites/default/settings.php
This turns off all errors / warnings and is probably a good idea on a production system.
THE OTHER ISSUE IS MUCH MORE IMPORTANT THOUGH -
The garbled characters are also an issue with JSON encoding, but the problem, is these were not in my json response, they had been inserted into my index.php file. Not sure how that happened, except that this project had been on the client's insecure servers for a while before moving to our secured servers, so I traced it back to before that switchover. I removed all of this nonsense code (you will recognize it as gibberish javascript) and bingo, Drupal is back up and running. Check your index.php first, and then maybe look into other files. You can look at any page on your site and scroll through it and you should see the gibberish there as well. Get that out of there!
Good luck
ponticlaro
Comment #130
snovak CreditAttribution: snovak commentedI solved the problem in my case. I had APC (php extension) handling my uploads. It's cool to watch my the file progress, but after I took
apc.rfc1867 = 1
out of my php.ini, file uploads are working again.If you check your status report (admin/reports/status) in the upload progress row, mine works as disabled.
I will eventually install PECL uploadprogress to see if that has any issues.
Hope this helps
Comment #131
rfaySince we now have issue summaries, could someone write a summary of this classic issue (just by editing the node) and provide future users a list of the various workarounds that have been described here?
Comment #132
mayank-kamothi CreditAttribution: mayank-kamothi commentedIncrease your upload limit
ini_set('memory_limit', '512M');
ini_set('upload_max_filesize','8M');
Add this in you setting.php file.and once clear cache .
Comment #133
DaPooch CreditAttribution: DaPooch commentedWell, to add to the many list of things that worked. For me my issue was that I migrated from a server using mod_php to a new one using fastcgi. The request length was too short for any files over about 90k which is why small files worked but anything bigger didnt.
Long story short I needed to add this configuration to my php.conf script
MaxRequestLen 15728640
Hope that helps someone spend less than the damn 8hours it took me.
Comment #134
lord777 CreditAttribution: lord777 commentedit worked with IE8
try it
Comment #135
selinav CreditAttribution: selinav commentedWe have the error http 0 for filesize > ~13M
It works on localhost but not on shared hosting (ovh Webpro)
The problem is the same whatever the browser.
I've tested a lot of top suggestions but nothing work, is there a fix today?
EDIT -------
It works also on VPS.
Comment #136
rayvan CreditAttribution: rayvan commentedFlush all caches worked for me.
Comment #137
Theo CreditAttribution: Theo commented#113 worked for me. Thanks rfay. At the bottom of every page we appended performance information to the HTML which caused the HTTP Error 0 in the ImageBrowser module.
Comment #138
happyend-re CreditAttribution: happyend-re commentedThanks andypost for your comment and patch. My opera 10 browser now work with drupal 6.22. I don't know why use in newer drupal this old jQuery Form Plugin (version: 2.01 since 10/31/2007)...???? I work hard my website development with this fake error... Thanks so much!
Comment #139
Jalandhar CreditAttribution: Jalandhar commentedComment #140
rfayThis issue definitely needs an issue summary summarizing the problems, causes, and workarounds.
Comment #141
Jalandhar CreditAttribution: Jalandhar commentedHURRAY...I Got It....
I installed the jquery update module and its fixed.
Install the jquery update from:
http://drupal.org/project/jquery_update
Comment #142
ronsnow CreditAttribution: ronsnow commentedThis problem popped up for me just yesterday. We have a stable environment and a user wanted to attach some files to some standard content (type=page) he was editing. The first few days all was great and files were attached. Perfect. Then, without any changes to the environment it seems to now get this HTTP Error 0 problem every time he tries to Attach a file to any content - the problem occurs when he presses the Attach button.
The strange thing is that I can see on the server that the file actually did transfer to the host and if he then simply ignores the error and uses the Save button for the content, the node seems to be properly updated and the attached files show where the should on display.
I have tried rebuilding permissions, clearing all cache (Drupal and Browsers[FF, IE, Safari, Chrome, Opera]), insuring file and directory security on host (linux/apache). I just don't see that it could be host related as it was working just 2 days ago on a server environment that does not change. It seems users were running into the problem and many still were seeking resolution....
Did anyone find a way to clear the problem?
Comment #143
ehowland CreditAttribution: ehowland commentedI was having disk quota problems on my shared hosting site. This stopped when I deleted some backups.
Comment #144
igorak CreditAttribution: igorak commentedThe solution for me was little bit different, but maybe helpful for some here.
On our server we got a nginx befor apache server.
We needed to change the client_max_body_size of the nginx.conf.
http://recursive-design.com/blog/2009/11/18/nginx-error-413-request-enti...
Comment #145
mattcasey CreditAttribution: mattcasey commentedSwitching to ImageMagick fixed the problem for me. I could not upload large image files (~1MB) because of this error. I tried a lot of solutions, disabling modules and editing settings.php, editing php.ini, etc. Running on a FreeBSD server with Verio hosting. Turned out it was already installed on the server, I just had to set the folder to "/usr/local/bin/convert" instead of "/usr/bin/convert"
Comment #146
mrfelton CreditAttribution: mrfelton commentedHit this again on another server / another site. The problem was environment specific (could not reproduce locally). It was related to the recent change where we forced the entire /admin part of the site over SSL. One of our modules uses ajax callbacks in order to regenerate a list of options based on a selection from another field. This ajax callback url was not included in the list of urls that we force into ssl, and we perform 443->80 redirection for all other URLs. So, when the callback url was requested over ssl, nginx was attempting redirecting to non-ssl - the redirect on the ajax callback url was messing with the JS behaviour and causing this familiar error message.
So: if you do ssl <-> non-ssl redirections make sure that your ajax callback urls are excluded from this, preferably making them available over both protocols.
Comment #147
rfay@mrfelton, #146, this is a classic problem.
I personally think that using partial site SSL is a relic of an earlier age, and that all sites that need SSL (which is probably now most sites in the age of firesheep) should just SSL the whole site and skip this entire problem.
Comment #148
mrfelton CreditAttribution: mrfelton commented@rfay - I completely agree, and these days we always push clients to do that where possible. Unfortunately due to the shortcomings of other services such as Issuu - that do not support SSL, it is not always possible to have an entire site run in SSL without bothering IE users with warnings about insecure content. Shame, but we don't live in an ideal world!
Comment #149
Studio FJ CreditAttribution: Studio FJ commentedWe 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
Comment #150
ThaboGoodDogs CreditAttribution: ThaboGoodDogs commentedOk, I was getting this error on a very simple site from 2007! Started out by doing an update to core to 6.13 > 6.28 but still got same error. I even changed the jquery.form.js as described by the gent above but nothing. I went into permissions and changed the uploads to be allowed by authenticated users and now it works. Perhaps there was something screwy with my permission on the server but fixed in about two hours of messing about :)
Comment #151
selinav CreditAttribution: selinav commentedI've tried a lot of solution, on a OVH Shared host:
- increase memory_limit, post_max_size, upload_max_filesize in settings.php and cleared cache
- install jquery update
- replace jquery.form.js (last version)
- change upload permission
I've the HTTP 0 error message on attached button
and
Fatal error: Out of memory (allocated 50331648) (tried to allocate 13056 bytes) in /mysite/sites/all/modules/imageapi/imageapi_gd.module on line 59
Have you got an idea?
Comment #152
mattwmc CreditAttribution: mattwmc commentedHave the same problem.
I'm using the Ads module and trying to attach an image. Page gets redirected to Access Denied --> /upload/js
Tried everything.
Any chance it's a permissions issue? Where is that js located?
Comment #153
rayvan CreditAttribution: rayvan commentedThis comment's recommendation worked for me. I just had to increase the PHP memory limit afterwards. Thank you!
http://drupal.org/node/240777#comment-6795652
Comment #154
carpo CreditAttribution: carpo commentedJust wanted to mention how I fixed this, as I don't think anyone else has mentioned this specific issue from my reading of this thread.
In my case it was caused by mod_fcgid in Apache. The default MaxRequestLength will only allow 130KB or less (changed from 1GB in previous versions). Looks like this was a change in v 2.3.6 of mod_fcgid (http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidmaxrequestlen).
it was baffling me, as I moved the code from one server to another, and all the configuration looked the same, yet it failed still. To fix, you need to add the following to your apache config:
<IfModule mod_fcgid.c>
MaxRequestLen 40000000
</IfModule>
Hope this helps someone - this has been plaguing me for months!!!!
Comment #155
fmitchell CreditAttribution: fmitchell commentedI ran into this recently.
I'm hosted with GreenGeeks and they added this to my htaccess file:
SetEnv PHPRC /path/to/site/php.ini
Comment #156
othermachines CreditAttribution: othermachines commentedAn apostrophe in the file name will generate this error.
Comment #157
pietrocap CreditAttribution: pietrocap commentedDrupal 7.34 - I was struggling with this issue and I confirm that it was due to an apostrophe as #156
Comment #159
Piyushchandra07 CreditAttribution: Piyushchandra07 commentedHi
can you all can you have the Secure Pages module . If you have then check the who is secure by them and customize them .
thanks