I have a really odd 301 redirect failing issue that I can't seem to wrap my head around why.

I have a netscaler device with responder policies that move http traffic onto https and naked domain traffic onto www.

  • They are working perfectly on Windows desktop devices through Chrome and Firefox.
  • They are working perfectly on mobile devices tethered to Wi-Fi.
  • They are working perfectly on mobile devices on 4G with Sprint and T-Mobile.

They are completely failing on AT&T 4G.

enter image description here

I have tested this with a multitude of Android devices and iOS devices on AT&T and all exhibit the same issues: a 504 response. Here is the output which I got by tethering my phone to my PC and firing up Fiddler.

GET http://thedomain.org/ HTTP/1.1
Host: thedomain.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1

HTTP/1.1 504 Fiddler - Receive Failure
Date: Thu, 10 Nov 2016 22:20:27 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Cache-Control: no-cache, must-revalidate
Timestamp: 16:20:27.867

[Fiddler] ReadResponse() failed: The server did not return a complete response for this request. Server returned 0 bytes.                                                                                                                                                                                                                                                                                                                                                                          

I obviously have begun the process of speaking with AT&T about this, but has anyone any suggestions at all as to why this may be occurring? My whole team is stumped at present.

UPDATE 11/11 09:30

So these were the exact issues we were experiencing yesterday


  • Opening the Android stock web browser specifically and typing into the address bar: thedomain.org
  • Opening the Android stock web browser specifically and typing into the address bar: www.thedomain.org
  • Opening any web browser on mobile and typing into the address bar: http://www.thedomain.org
  • Opening any web browser on mobile and typing into the address bar: http://thedomain.org
  • Opening any web browser on mobile and typing into the address bar: https://thedomain.org

The network provider was quick to blame AT&T. However!

They added a rule for the last use case which was failing on all networks to redirect https://thedomain.org to https://www.thedomain.org and lo and behold it also fixed the rule for AT&T users. I still don't know why yet, I am guessing some kind of refreshing of the rules in netscaler fixed the issue on the load balancing device, but as I stated to them, I'd take a fix over an explanation in the short term.

If simply re-applying the rest of the rules is the fix, I will update this with an answer.

  • 2
    Have you attempted to make the same request (exact same headers) from a different network? Given the "gateway timeout" error, it appears that it is a failure of your netscaler device. Maybe it is related to the Upgrade-Insecure-Requests header. Commented Nov 10, 2016 at 23:42
  • Thanks for the suggestions, @stephen-ostermiller I will certainly give them a go. Commented Nov 11, 2016 at 0:03
  • But these are the request headers as sent from your browser. What you aren't seeing are the request headers after they've passed through (and possibly been mashed by) AT&T's servers, before they hit your server / netscaler device.
    – MrWhite
    Commented Nov 11, 2016 at 1:08
  • Indeed, @w3dk I'm working with our network company to get hold of the netscaler logs. What would you anticipate seeing to the headers? Have you seen something similar? Commented Nov 11, 2016 at 1:09
  • I don't know, I would hope the headers would be largely unchanged. But mobile networks certainly do intercept (and "play with") the original request in order to save bandwidth.
    – MrWhite
    Commented Nov 11, 2016 at 1:17

1 Answer 1


I would recommend that you do detailed analysis of the FQDN(fully qualified domain name) dns lookup from each network separate from the html requests. If the dns entries for your domain do not have the appropriate records to associate the domain name minus the host component with the ip address of the web server it is to a certain extent related to missing dns record entries.

A number of cellular providers appear to be using proxy servers for web browsing...so the error you have regarding missing content may actually be an indication that the dns lookup failed on the web-proxy....so you are getting a different message than if your browser were going direct and the dns failed.

  • Interesting thoughts, @webmite, I appreciate you taking the time to respond. We ended up dumping this provider due to several issues with their infrastructure including this one, so I never got the opportunity to get to the bottom of it. Commented Apr 21, 2018 at 21:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.