I have a very wired "Too Many Redirects" error being reported on an HTC mobile phone.

My site is simple, using a javascript

<script type="text/javascript">
  if (screen.width <= 800) {
    window.location = "";
  }
</script>

The script works fine on iphone and blackberry. The ecript also works fine with HTC phone when the phone is connected via WIFI. However when the HTC device is connected via 3G it reports error "Too Mnay Redirects". (I've test on two different networks).

Does anyone have any ideas?

p.s. I tried a number of redirect methods (inclusing a PHP 301 header readirect).

Dani AI

Generated

A short, practical diagnosis and checklist for a redirect loop that only shows up on a specific phone/network (helps clarify ’s browser/OS question and gives next steps for ).

Such failures are commonly caused by one of three things: a carrier-side transparent proxy changing headers or caching responses, server-side host/URL canonicalization that bounces between two hosts or protocols, or redirect logic that doesn’t guard against “already-on-target” states. The immediate goal is to capture the exact redirect chain and the headers the phone sends (User‑Agent, Via/X‑Forwarded‑For, Location headers).

Run a header-only request from a machine where the HTC User‑Agent is supplied (copy the UA from the phone) and inspect every Location value. Example:

curl -I -v -A "PASTE_HTC_USER_AGENT_HERE" "http://your-site.example/"

Compare that to the same request without the UA and to requests that include common proxy headers. If Location alternates between two hosts or between http/https, that’s the loop.

Server-side checks to perform next: examine access logs for the failing requests (timestamps, remote IP, headers), search rewrite rules (.htaccess, nginx vhost) for conditionals that might flip based on Host, UA, or Accept headers, and look for injected proxy headers (Via, X-Forwarded-For). Test the phone behind a VPN (or with data-saver off) to see whether bypassing the carrier proxy removes the problem.

Mitigations that reliably stop loops: make redirects idempotent (only redirect if Host != target host), canonicalize www/non‑www and http/https consistently, avoid client-side screen-width redirects as the only solution, and use a short-lived cookie or a server-side detection library to prevent repeated redirects. Collect the phone’s User‑Agent string and the full sequence of Location headers when debugging—the pattern there usually reveals the culprit.

What browser are you using, and which version/build of Android is it running?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.