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?

Files: 
CommentFileSizeAuthor
#110 Acchi_Kocchi.jpg12.38 KBhaclong99
#59 ajax_example_http_error_0.tgz4.06 KBrfay
#53 240777_jqForm.patch17.42 KBandypost
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 240777_jqForm.patch.
[ View ]
#48 jquery.form_.js_.txt10.27 KBandypost

Comments

Version:6.1» 6.4

I'm getting this, too. I think it might have to do with poorly written AJAX modules.

I'm investigating whether this issue is the same as #279106: Upload Module Error 0?.

Is this reproduceable with 6.5?

Version:6.4» 6.6

I'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:

An HTTP error 0 occurred.
/drupal/?q=upload/js

Reply with your htaccess rewrite rule. You might need to escape your dot. \. Because it could be interpreting upload.js as upload/js or vice versa since . means "any character."

Here's the rewrite section I found in .htaccess:

# Various rewrite rules.
<IfModule mod_rewrite.c>
  RewriteEngine on
  # If your site can be accessed both with and without the 'www.' prefix, you
  # can use one of the following settings to redirect users to your preferred
  # URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
  #
  # To redirect all users to access the site WITH the 'www.' prefix,
  # (http://example.com/... will be redirected to http://www.example.com/...)
  # adapt and uncomment the following:
  # RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
  # RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
  #
  # To redirect all users to access the site WITHOUT the 'www.' prefix,
  # (http://www.example.com/... will be redirected to http://example.com/...)
  # uncomment and adapt the following:
  # RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
  # RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]
  # Modify the RewriteBase if you are using Drupal in a subdirectory or in a
  # VirtualDocumentRoot and the rewrite rules are not working properly.
  # For example if your site is at http://example.com/drupal uncomment and
  # modify the following line:
  # RewriteBase /drupal
  #
  # If your site is running in a VirtualDocumentRoot at http://example.com/,
  # uncomment the following line:
  # RewriteBase /
  # Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_URI} !=/favicon.ico
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>

**EDIT**
I just checked sites/default/files, and the file I was attempting to upload was uploaded successfully, yet I got the error... *confused*

If 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?

I 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.

I 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

I'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;

<script type="text/javascript">
<!--//--><![CDATA[//><!--
jQuery.extend(Drupal.settings, { "basePath": "/", "ahah": { "edit-attach": { "url": "/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" } } }, "teaserCheckbox": { "edit-teaser-js": "edit-teaser-include" }, "teaser": { "edit-teaser-js": "edit-body" }, "tableDrag": { "upload-attachments": { "upload-weight": [ { "target": "upload-weight", "source": "upload-weight", "relationship": "sibling", "action": "order", "hidden": true, "limit": 0 } ] } } });
//--><!]]>
</script>

This shows us actually "/upload/js" is inside the code.

Version:6.8» 6.6

which 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

Version:6.6» 6.8
Priority:Normal» Critical

It 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?

Priority:Critical» Normal

I try to capture with firebug.

There are headers;

Response header;
Date Tue, 16 Dec 2008 08:38:59 GMT
Content-Length 2932
Content-Type text/html
Server NetCache appliance (NetApp/6.0.6P2)
Proxy-Connection close
Proxy-Authenticate NTLM Basic realm="webauth"
request header;
Host xxxx.xxxxxx.org
User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language ja,en-us;q=0.7,en;q=0.3
Accept-Encoding gzip,deflate
Accept-Charset UTF-8,*
Keep-Alive 300
Proxy-Connection keep-alive
Referer http://xxxx.xxxxxx.org/node/add/page
Cookie SESSd874d9536d18efe576cc98806841ff2b=b8c2c099620fd8a1190b70b1897420a6; icid=0; idsc=0; ih1=264; ih2=132; iw1=132; iw2=440; SESS387834af71177b5072a7e52bfdb53180=5e77f380e3ae9b277eab5123ee09eb1d; has_js=1

response is as follows;

{ "status": true, "data": "\x3cdiv class="messages error"\x3e\nValidation error, please try again.
If this error persists, please contact the site administrator.\x3c/div\x3e\n" }

I 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.

I 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.

Version:6.6» 6.8

Any updates on this?

Hi.

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.

Version:6.8» 6.9

Just 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

Hey, 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.

This 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.

subscribing

I get something similar to this with AHAH stuff where it will commit the action yet return an error message.

To 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

Oops! In devel module by disabling 'Display whatever' options, the problem is eliminated. So I think this is a devel.module issue...

Thanks @jcfiala!

simple
look apache configuration = sites_enabled

"alias /upload/"
rename alias /uploads/ or etc..

no problem.

Version:6.9» 6.10

Ok, 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?

I 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.

Hello,

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

Problem also occured on my production server, no problemo on localhost MacBook.

From my Apache error log, I grabbed the following error:

[Fri Jun 05 16:01:54 2009] [error] [client 172.20.*.*] File does not exist: C:/inetpub/wwwroot/sites, referer: http://****/aqua-sandbox/node/add/bestand
'file' is not recognized as an internal or external command,
operable program or batch file.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.

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

Version:6.10» 6.13

Still fails in Opera. Works fine in Firefox and Safari. Tested on a Mac.

Subscribe.

I 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:

        if ($.browser.msie || $.browser.opera)
          io.src = 'javascript:false;document.write("");';

I 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!

I 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?

Title:Attach: An an http 0 occurredAttach: An http 0 occurred

I 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?

a 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

Linux, 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

subscribing

subscribe

I'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.

Version:6.13» 6.9

It 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.

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr"
      xmlns:dc="http://purl.org/dc/elements/1.1/"
      xmlns:foaf="http://xmlns.com/foaf/0.1/"
      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

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.

this 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 :(

Same problem with 6.14. No luck to solve it via one of many methods proposed. It really pisses me off :(

There 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.

Version:6.9» 6.x-dev
Component:upload.module» javascript

Confirm 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

Could 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.

Version:6.x-dev» 7.x-dev
StatusFileSize
new10.27 KB

Same 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/

I 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.

Originally, 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.

Version:7.x-dev» 6.x-dev

I'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

Version:6.x-dev» 7.x-dev
Status:Active» Needs review

This should be fixed in HEAD first

StatusFileSize
new17.42 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 240777_jqForm.patch.
[ View ]

Patch against HEAD (file from #48)

Might as well use the latest version. Was released on Nov. 7 2009. http://jquery.malsup.com/form/jquery.form.js?2.36

@te-brian do you test this version with file/image upload?
2.28 works fine but 2.35 dont

@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.

I agree that we should try to upgrade to the latest version instead.

@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.

StatusFileSize
new4.06 KB

Maybe 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.

It 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+.

One 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

@rfay: did you really intend to link to the same issue twice ?

@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.

Thanks, it`s work for me:)

I 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.

Here you go, gents: #609622: Keep jQuery Form up to date . Let's keep issues on track.

Status:Needs review» Active

So the latest JQuery form got committed on January 18. Please check to see whether this issue can be marked fixed.

The 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).

Version:7.x-dev» 6.15

Same 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

drupal92037 did you try #53

Title:Attach: An http 0 occurredAttach: An HTTP Error 0 occurred
Version:6.15» 7.x-dev

Let'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.

subscribe

related 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)

Thanks 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.

#53 did not help with this error in Chrome (taxonomy/autocomplete/7)

Subscribing

In 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).

@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.

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

Version:7.x-dev» 6.15

Just 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.

Version:6.15» 7.x-dev

@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.

subscribing

Version:7.x-dev» 6.2

None 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.

Version:6.2» 7.x-dev

Until this is confirmed fixed on 7.x, please do not change the version number.

Issue tags:+ajax upload problem

We 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

I'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.)

I 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.

I'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:

  • I choose a file to attach.
  • Click "Attach" button.
  • Two message boxes with "HTTP Error 0" and "Security warning: data is sent unencrypted..." appear.
  • I click both away (OK / Continue)
  • Attachment list on the edit page does not show the new file.
  • The file is not yet on the server.
  • I click "Save". --> browser shows http://my-site.de/upload/js with "{ "status": true, "data": "\x3ctable id=\"upload-attachments\" ..." stuff similar to what's reported in #434394: 'HTTP error 0 occurred' on image upload.
  • The file is uploaded to the server.
  • I push "back" button in the browser, click on "View" to view the page --> the attachment is not listed.

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:

  1. Disabling JavaScript, of course.
  2. Now for something different: disabling Firefox option "Security -> Warnings -> Warn if data is sent unencrypted." helps.

HTH,
Peter

I 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.

subscribe

Ok,

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.

Got the same problem. I can't upload anything in any module or any content. Everything is 777 in my folders.

Safe Mode issue ?

@eyildiz: If you're working with D7, then you got a far more significant error message, so please make sure to post it.

Version:7.x-dev» 6.16

For 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.

For 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

You 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...

Only 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

#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.

#97 seems to have worked for me.

uninstall devel module worked for me!

disabling it alone does not work.

I 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.

  1. Checked if it happens in different browsers
  2. Increased memory and upload limits in PHP
  3. Did the same for Nginx. This solution worked for a different site, but not this time.
  4. Checked folder permissions
  5. Installed jQuery Update module and use jQuery 1.3
  6. Turned off 'Optimize JS / CSS files' in Performance
  7. Checked /tmp and set upload_tmp_dir to /tmp in php.ini
  8. Turned off reverse-proxying in Nginx
  9. Downgraded to PHP 5.2. Problem solved!

Downgrade 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.

This 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.

Worked for me. Thx

Solved.

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.

I 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

@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.

Thank you so much, rfay

I fixed this problem by changing $base_url from 'http:' to 'https:' in settings.php.

Version:6.16» 6.19
StatusFileSize
new12.38 KB

I'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.

For 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.

Looks 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.

The 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.

So, 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()

Ajax callbacks in upload module:
- upload/js -> upload_js(), user_access('upload files')

Same recommendations as in #114 above.

Hi,

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:

  • post_max_size
  • upload_max_filesize
  • memory_limi

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.

I 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

The cache might be corrupt. Try Clearing the cache, this worked for me. (Also, I was using file minimization)

Status:Active» Needs review
Issue tags:-ajax upload problem

#53: 240777_jqForm.patch queued for re-testing.

Status:Needs review» Needs work
Issue tags:+ajax upload problem

The last submitted patch, 240777_jqForm.patch, failed testing.

I 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.

@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.

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

I 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';

Version:6.19» 6.20

I 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?

I 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.

After 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!

Today 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!

I 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

I 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

Title:Attach: An HTTP Error 0 occurredAttach: An HTTP Error 0 occurred (on file upload)

Since 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?

Increase 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 .

Well, 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.

it worked with IE8
try it

We 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.

Flush all caches worked for me.

#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.

Thanks 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!

This issue definitely needs an issue summary summarizing the problems, causes, and workarounds.

HURRAY...I Got It....

I installed the jquery update module and its fixed.

Install the jquery update from:
http://drupal.org/project/jquery_update

Version:6.20» 6.22

This 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?

I was having disk quota problems on my shared hosting site. This stopped when I deleted some backups.

The 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...

Switching 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"

Hit 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.

@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.

@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!

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

Ok, 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 :)

I'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?

Version:6.22» 6.28

Have 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?

This 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

Just 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!!!!

I ran into this recently.

I'm hosted with GreenGeeks and they added this to my htaccess file:

SetEnv PHPRC /path/to/site/php.ini