Error when editing content, loggin in, and others

I have the same issue here. However, the host ipage won't allow me to install drupal myself. I had to use the simple service they offer to install it.

what host do you use?

What do your logs say? Do you have access to your core drupal files and /sites?

I would also check your permission on your install?

What does your site look like @ example.com ?
Do you have your .htaccess file at public_html/.htaccess

The 302 is detailed as follows?
HTTP Error 302 - Moved temporarily

Introduction

Your Web server thinks that your URL has been temporarily redirected to another URL. The client system is expected to immediately retry the alternate URL.

302 errors in the HTTP cycle

Any client (e.g. your Web browser or our CheckUpDown robot) goes through the following cycle when it communicates with the Web server:

Obtain an IP address from the IP name of the site (the site URL without the leading 'http://'). This lookup (conversion of IP name to IP address) is provided by domain name servers (DNSs).
Open an IP socket connection to that IP address.
Write an HTTP data stream through that socket.
Receive an HTTP data stream back from the Web server in response. This data stream contains status codes whose values are determined by the HTTP protocol. Parse this data stream for status codes and other useful information.
This error occurs in the final step above when the client receives an HTTP status code that it recognises as '302'.

Resolving 302 errors - general

The 302 response from the Web server should always include an alternative URL to which redirection should occur. If it does, a Web browser will immediately retry the alternative URL. So you never actually see a 302 error in a Web browser, unless perhaps you have a corrupt redirection chain e.g. URL A redirects to URL B which in turn redirects back to URL A. If your client is not a Web browser, it should behave in the same way as a Web browser i.e. immediately retry the alternative URL.

If the Web server does not return an alternative URL with the 302 response, then either the Web server sofware itself is defective or the Webmaster has not set up the URL redirection correctly.

Resolving 302 errors - CheckUpDown

Redirection of URLs may occur for low-level URLs (specific URLs within the Web site such as www.isp.com/products/index.html) when you reorganise the web site, but is relatively uncommon for the top-level URLs (such as www.isp.com) which most CheckUpDown users ask us to check. So this error should be fairly infrequent.

The 302 response from the Web server should always include an alternative URL to which redirection should occur. If it does, CheckUpDown automatically tries the alternative URL. This in turn may possibly lead to another redirection which CheckUpDown then tries. This continues for a maximum of 5 redirections. As soon as 5 redirections have occurred, CheckUpDown gives up and reports the 302 error for your account. So you should only ever see the 302 error if 1) the Web server gives no alternative URL on the 302 response or 2) the number of redirections exceeds 5. This second condition should be fairly unlikely - and may indicate a recursive pattern e.g. URL A redirects to URL B which in turn redirects back to URL A.

You first need to check that the IP name we use to check for your account is accurate. If you or your ISP have configured something so that any access using this name should now be redirected to another name, then you need to update your CheckUpDown account to start using the new name.

If you believe that the IP name we use is exact (should not be redirected), please try accessing the current URL using a Web browser. Note carefully which URL actually gets displayed, because your browser may silently switch to a substitute URL if it receives an 302 message from the Web server. If you see any evidence of a new URL, try accessing that directly from your browser. If this works (you see the Web site as expected), then this new URL is what you may need to update on your CheckUpDwon account. If this is a temporary redirection, then you may also need to reinstate the original IP name at a later date when the redirection is no longer effective.

If none of the above help, we can analyse the underlying HTTP data streams we receive from the Web server. These can provide additional information about the new URL(s) which the Web server thinks we should be accessing. Before doing this, we prefer you to identify any deliberate changes on your side, liaising with your ISP if needs be.

302 errors should occur infrequently, because top-level URLs do not change often. If they do change, then this is typically because a redirection URL is being suggested. This pervasive change is unlikely to occur by accident, so most often we can resolve this error by updating our system records for your account following a deliberate change of URL on your part, whether this change is temporary or permanent.

What is Fatcow running? LAMP AND YOUR ON WAMP?

If you think this is solved lets close it:)

I have the same issue, only it occurs in Chrome (27.0.1453.94 m), and firefox (21.0).
On IE (9.0.8112), everything works fine.
I've deleted all cookies, cleared caches, all in vain.

Any entries in your log? Is your drupal install all up to date? What theme are you seeing this in chrome? Is your .htaccess file "default" not modified?

Nothing in the log files.
Drupal core & modules are all updated.
My .htaccess file is the default.
It happens in all themes (Garlans, Bartik, Seven).
HOWEVER, when using the https protocol (with SSL/TLS support), as well as when forcing it on the site (using KB SSL enforcer), everything works perfectly.
It seems that it has to do with updates made to FF and Chrome relating to SSL/TLS, but I can't find the solution.
It happens on 2 twin sites hosted on different servers.

OK, I was able to pin point the source of the problem but not the 'proper' solution:
When clean URLs is disabled, everything functions well (aside the fact that the url is now /?q=user, instead of /user.
I rechecked it with a fresh installation (7.22), and this applies!
Were there any changes to this component?

I would check to make sure the following is enabled:

Step 4: sudo a2enmod rewrite (this is vital for clean urls.)

You can run this in your terminal but I am on LAMP. The main idea being make sure apache2 rewrite is enabled. :)

Hope that helps...

Should we close this ticket. I would say this is a closed issue.

This just started for me today for only one of my sites.

Running 7.22. This one is hosted at iPower.com.

I don't think it is "closed."

0<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://www.immaculateconceptionchurchwhb.net/admin/config/system/backup_migrate?render=overlay">here</a>.</p>
<p>Additionally, a 302 Found
error was encountered while trying to use an ErrorDocument to handle the request.</p>
</body></html>
HTTP/1.1 200 OK
Date: Mon, 17 Jun 2013 11:56:38 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 19314
Connection: keep-alive
Server: Apache/2
X-Powered-By: PHP/5.3.13
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Mon, 17 Jun 2013 11:56:37 +0000
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
ETag: "1371470197"
Content-Language: en
X-Generator: Drupal 7 (http://drupal.org)
Vary: Cookie

Did any of the above solutions help?

I have the same issue. Can't figure out why it's doing this. Random admin pages show the same code susgeek posted. If I click refresh, it reloads fine. I have 2 sites doing this right now. Seems to be connected to updates...

Any information in your log?

Are you caching and compressing your .css, ajax and .js files? @performance ?

What is your settings on admin/config/system/backup_migrate? module? Is the site sticking in maintenance mode and or any other issues?

Since the backup && migrate module is in the path I would check that module and or disable it.

I would additionally check your php.ini file located @ status.

Hope that gets things moving for you...

Hello,

The problem happens only when Avast antivirus is active in Windows with Chrome and Firefox.

Someone have this issue with other hosting but ipage?

Regards

I just joined to add my bit to this problem, as I also have it, but on Wordpress. I use wordpress on three separate hosts, but only one of these hosts gives me this exact same problem.
That host is iPage.

I have seen that you have the problems on fatcow and ipower

The ONLY common demoninator is that ipage, ipower and fatcow all use the vDeck panel. My other hosts use Cpanel.

ipage and fatcow apparently use the same systems, and I have read that they share the same computers.

I know that Endurance International Group owns all three, but they also own the other two that I use, which don't have the problem.

Can it be something to do with the vDeck panel ??

The sites I am having problems with are on FatCow (vDeck) also. I also figured out that the computers affected are using Avast. Disabled it for 10 minutes and didn't have a single issue.

I think this might be a conflict with Avast and how it's scanning the sites. Not sure how to fix it and not having clients use their anti-virus isn't an option.

Is anybody else using Avast?

I use Avast and my issue is on Chrome and Firefox. It doesn't appear on IE.

And it is only on the Drupal installion I have on iPower.

I have a couple SilverStripe installations on iPower and they are not affected.

My Drupal installations on HotDrupal are unaffected.

I turned off overlay, thinking that was the problem, but it didn't stop it.

I have Windows 7 professional.

It seems we are narrowing down the variables.

The other computer here uses AVG and has had no issue with the same Drupal installation.

Thanks susgeek! That helps confirm things for me. It must be the way those hosts are sending the data. My other D7 sites are not having issues (local installations and private servers). Only FatCow and only when Avast is running.

Not sure. We haven't figured anything out ourselves other than pausing Avast for a few minutes while working on the site(s) in question. Not an optimal solution, but a solution none the less.

...and we only pause the Web Shield. So you don't have to turn it completely off. As long as the web shield is disabled we haven't been running into issues.

JohnGuy, our issue is with the drupal admin system in house. We haven't had any issues with the front end and our clients aren't having much trouble. Only one or two of the sites in house are having problems. And of course we use Avast and our clients use whatever came with their computers (Norton, McAfee, etc) But you are correct, can't tell clients or front end users to turn off their anti-virus. We just do it in house since we have control over the machines and those were a one time edits. It's a duck tape work around for an issue we don't have a solution for yet. Others can do the same but the risks are on them. We just wanted to post what was conflicting. Maybe it will help someone find a solution. Not really sure... it might be up to Avast itself.

Will keep everyone posted if we figure anything out. So far, nothing good.

I do have the same problem and I'm using Avast! too.
I'm hosting at Fatcow too. :)
And for now I've tried disable avast's web shield feature and the problem solved for now.
I'm on Windows 7 Ultimate 64-bit and using Chrome 27.x.x.
Haven't tried it on other browsers yet because it's a brand new site and has been working on Chrome since.

First Drupal.org post!

I am having this issue as well. I am hosted with Fatcow and their support on the matter is pitiful. This is my first ever experience with Drupal, but I am no stranger to static web design and hosting (since 98).

I get the issue in /admin only and on Firefox/Chrome (not IE).
I am using Kapersky Internet Security 2013 on my local machine, not Avast! or AVG.

It doesn't always happen, but it constantly occurs whenever I try to install a theme (as seen in attachments). I would also intermittently get it when I tried to save configurations (such as enabling clean URLs). I would also get it every time I accessed /admin for the first time. A refresh usually clears the issue on all but the failed theme installation attempts. Luckily, it has never occurred outside of the admin portal.

Fatcow support kept trying to insist that my theme .zip was corrupt, but my Drupal friend was able to install it on his machine (see confluencecrafts.com). Figuring out this frustrating issue will be amazing to this noob!

My info:
Drupal 7.22
Fatcow hosting (one-click installation)
Chrome Version 28.0.1500.72 m
Firefox v22.0
IE 10.0.9200.16635
Kapersky Internet Security 2013
Windows 7 64-bit Home Premium, SP1

We are just sitting in on this issue. We are not seeing the error our selves so we really do not like to talk about "What we do not know" but here are some thoughts...

@rootsrundeep thanks for your great post... and welcome to Drupal:)

1. This seems to be caused by security software?
2. We run clamtk on Linux servers... and have noticed some modules are pinging virus script. One that comes to mind is the webform and Calendar module. You can see this when you run your scan on a drupal folder. We have not looked deeper into this due to the fact that it seems not to be an issue and is not causing any.
3. What about just moving hosting? There are a few companies that specialize in just Drupal Hosting as we do @ http://jooblay.me Sorry for the plug... It is hard not to some times.

Can you scan your drupal folder and see if any scripts ping "WARNING" ?

Power to the community:)

Updating the issue to give more information.