Weird: website refuses to load (empty content)

Only happens via hotspot-cellphone, IP problem?

[explorador]

Hi webmasters, I can't figure this out. I have access to 3 networks at the office, all from diff service providers and I can even activate a 4th from another company. My websites stopped working on one. And no I was not blocked by that company.

I have a cellphone providing WIFI to the office via hotspost (Android), it's been working just fine and never modified. The thing is since yesterday my laptop won't load MY websites. Yes I can browse everything else, google, youtube, etc. Tested the cellphone and YES I can browse my websites on the cellphone, it's just via hotspot that the websites won't load. What confuses me is how this affects specifically MY websites, all of them hosted at some hosting company. It's not a service provider block because I can visit them on the phone, it's just via wifi that I can't.

Tested my sites using the other networks and I have full access. Nope, the phone doesn't have a firewall, nope, it's not just my laptop, I can't browse the sites using anything else (another laptop, another smartphone, etc) anything connected to the hotspot in discussion. Reset? already. No clue. Any suggestions are welcome, or if this sounds familiar to you.

[explorador]

BTW I posted the thread here because I'm concerned on this being some software issue, perhaps server configuration, I have no clue but it doesn't look like a hardware issue.

[lucy24]

Preliminary question: Is the request reaching the site (server access logs)? If yes: Is any content returned? What numerical response code?

[explorador]

Thanks, the problem is really... weird. Now confirmed it has to do with the .htaccess file.

Sites been working perfectly, suddenly failed on one network and one network only (other isp working fine). Trying to test what's wrong deleted the htaccess file, sites loaded showing the directories. Placed the original file back and problems came back.

The funny thing is... it's not showing any single issue on any other network, confirmed from other countries too. It seems the htaccess has been cached somewhere. Changes on the website do show on all networks, except on that network IF the original htaccess is placed. Weird, it worries me. Will keep checking, will give at least 48 hours hoping the ghost file expires

[keyplyr]

The htaccess will not be cached.

Somewhere in the htaccess you possibly have blocked either the ip range or some process necessary for those requests to complete.

Can you remember what you last edited in htaccess?

Has there been any system or software updates at your server?

Why don't you use one of the backup htaccess files from your update history. I don't know how you do it, but I always keep 3 months history on my local machine for situations like this.

[phranque]

Is the request reaching the site (server access logs)?

Now confirmed it has to do with the .htaccess file.

this doesn't really answer the question.

Trying to test what's wrong deleted the htaccess file, sites loaded showing the directories. Placed the original file back and problems came back.

does your .htaccess internally rewrite those requests to a script?
if so, this isn't necessarily conclusive - it could be a problem in the script...

[lucy24]

Next basic question: You said at the outset that the problem is confined to one hotspot. Does this one hotspot have a different IP than all other requests?

I gotta say that when I first saw the subject line, I was reminded of a problem I had earlier this year when it turned out that on one site, images wouldn't display in iOS. Lots of red herrings, as the same site had just moved to HTTPS and got its own dedicated IPv6 address, none of which turned out to be relevant.

Instead the problem turned out to be that--stop me if you've heard this one--the last time I cleaned up the htaccess file, in one-and-only-one place I had "!." by mistake for "." (i.e.: thing is absent, vs. thing is present).

[explorador]

Thanks for the attention and help, It is working now. I would like to answer each question in depth, individually but that would be complex, at least it would be too long. Instead of answering point by point I will describe what I now see clearly, and how it started to work again.

As said before, I have access to several networks from diff isps. I was working on let's say Network4. Now I'm sure one htaccess file replaced the main one accidentally on a backup restore. It's fine (at least it should be fine) because as a fact, verified,
all those htaccess are the same, but somehow this was the beginning of the problems, the file was expanded from a zip (unix) file. Such file contains the files with their respective permissions.

Visiting the site then produced an error, empty response. Yes, the htaccess redirects everything that it's not a file to a main script (CMS). The original file was quickly put in place but the problem persisted. The original htaccess file was reviewed, it was ok, the permissions were ok, the line endings were ok, converted to unix line ending, all set, but still the same error. After fixing it (but seeing no results) I moved to a laptop that never visited the site, this to guarantee everything will be loaded directly with no cache in the middle. This laptop reproduced the same rror.

Quickly proceeded to review the site using all the other 3 networks, there was no error. This was reviewed after placing the original double-checked htaccess file. I can assure you everything was turned to it's original state, but the error remained on Network4, only affecting that website and similar stuff under that folder.

I proceeded to DELETE the htaccess file and I saw all my equipment being able to see the same: the directories. But when I put back the same htaccess file (original, double checked), network 4 reproduced the same error again. I factory restored the phone, no change. I trusted on having the original file all set as it was, and had to leave the office. The error was still there.

An hour later one of the devices worked fine again (on network4) while all the rest failed, on network4. Remember, all the devices worked perfectly on all the networks. It wasn't an ip block or anything alike, I could at all times connect via FTP and ping perfectly too. So I had to leave the office.

Checked again 4 hours+ later and another device started displaying the websites. Then 10 hours later ALL the devices started displaying the websites perfectly on network4 without any change made. It all works now. I can say it was the htaccess file. I had the website checked on other places, regions and countries, no error, the problem ocurred only on the computers using network4 by the moment of the file error, just like when a file is cached.


Htaccess cached? I do have experienced situations where I make a mistake on the htaccess file, let's say a period (without unescaping or whatever), and I get an error. Sometimes that error stayed after fixing the file, so in the meantime I had to continue working on another computer (or wait until "whatever" expires) another solution in such cases was renaming the folder and continue working. I'm sorry for the confussion, can't explain but this is the consistent behavior I managed to replicate again and again. I decided to explain in detail because I believe I owed that explanation and can also be useful to others.

[explorador]

And nope, there were no errors on the scripts, or ip blocking, just as insane as it sounds, a ghost copy of the wrong htaccess was causing the problem. Just as explained above.

The following thread on serverfault sounds very similar:
[serverfault.com...]

Another one here:
[stackoverflow.com...]

In this case it wasn't mamp or xampp, it was a live server on the USA running linux. It's said above that htaccess is processed each time a request is made, yet... I have detailed experiences proving the contrary, replicating the same error after deleting cachée(local cache) and even reinstalling the browser, waiting solved it those times.

[tangor]

Not saying this is an answer, merely a possible answer:

There's all different kinds of latency within the web. Sometimes it just takes time for the pipes to clean out and get new data, even if it is old data sent anew.

[phranque]

There is technically no way for a browser to cache a .htaccess file.
However the various responses from your various .htaccess files (or not) could have been cashed separately in your various browser configurations.
In addition it's possible that some of the responses could be cached by your ISP or some other type of intermediate proxy.

[robzilla]

To clarify, the client (browser) never even interacts with .htaccess. It's a local directive file for the Apache web server, parsed anew (expensively) for every single request within the directory hierarchy. The server response will be the same regardless of which network the client is on, unless there are network-specific rules in the .htaccess file. You've also ruled out your browser cache by factory-restoring the phone, so I would sooner suspect the networking software, equipment or provider to be at fault here, rather than the .htaccess file.

Is the site on HTTPS? That would rule out some possibilities of intermediaries snooping and potentially messing with your traffic.

[explorador]

Thanks, honestly... I feel very confused this in particular is not making any sense to me. Just as explained above, after a few hours it started working. Late night it was working. Today eary in the morning: not anymore.

Network4 is tied to internet service provider "CrazyMonkey" (made up name).
Network4 provides WIFI via cellphone hotspot, it's a cellphone, cellular data.
Site on other laptops and regions using same internet service provider "CrazyMonkey": IT WORKS.
So it seems like a problem with service provider CrazyMonkey or something on a hotspot basis.
Tried using other hotspots configured using other service providers: it works.
So it's not about hotspots, and it's not about CrazyMonkey service provider.

It all comes down to the WIFI provided by the phone tied to CrazyMonkey.
I'm not worried about "me" having the issue, but others on the same service provider.
While that sounds like a conclussion... things work when I remove the htaccess file.

So I have several variables:
(1) Wired networks coming from wired service providers, (2) wireless networks coming from diff service providers, (3) There are 4 diff companies providing internet, (4) htaccess file, (5) WIFI coming from wired networks, (6) WIFI coming from wireless networks.

It narrows to 2 + 4 + 6 on just one specific network provider only on that specific configuration.

My brain tells me this suggest some ip blocking or something like that, looks like something related to that network when it comes to WIFI via mobile, via cell data only. The evidence points that way. Doesn't make any sense to me relating this to the htaccess file, b but... even so, when it fails (and yes it is failing), things change when I remove the htaccess file from the server.

Need some coffee... It looks like someting in the middle affecting the traffic only when the htaccess is in place, while using CELL DATA on that specific network. Sounds to me like some proxy or traffic "enhancer" in the middle.

Nope, the site is not https yet.

[explorador]

Update, problem solved., but the mystery remains.

Yes, there is something in the middle on Network4 (ISP "CrazyMonkey") when using mobile data (doesn't happen on wired networks). It only happens there and doesn't happens on any other network (service provider) be it wired or cell-mobile-data.

As explained, htaccess removed in such circumstances showed te directories (no empty page)
Removed redirections on such htaccess file, it worked...
Narrowed it to a few Perl scripts (no it's not the script per se)
Tested and double tested until finding the lines causing the problem (no, it's not the Perl script)

It was about the cookie?. The CMS uses a few cookies, some for backend and one for front end. Removed the function that sets this cookie and everything worked perfectly. No, is not a scripting problem because the script works as expected on local linux server, on linux server at the US (3 of them) and on all the networks. It doesn't return "internal server error" or anything alike. The script works and has been working for quite some time.

3 conditions meet (tested again and again to confirm)
I can reproduce the problem consistently again and again, as long as (1) I try to set that cookie... to a client browsing on (2) Internet Service Provider "CrazyMonkey" while using (3) cellular data. Yes, as you read it, this problem only occurs while 1 + 2 + 3 conditions are provided. You can remone any of those (be it browsing on the same ISP by wire, or on another ISP, or just avoiding the cookie) and no error shows. Interesting huh? seems like they have something in the middle applied only to mobile data.

Thanks everyone for your suggestions, time and help.

Useful conclusion: if you are building websites sure you must test your sites against diff browsers and diff platforms, include testing it on diff internet service providers using diff methods (wired, wireless, etc).

[lucy24]

I need to comment on this:

I moved to a laptop that never visited the site, this to guarantee everything will be loaded directly with no cache in the middle

That's not, sadly, an absolute guarantee. In addition to browser caching, there can be remote caching by the ISP. When you reload in the browser, this may or may not force the ISP to re-request the page from the source. Only the ISP can say. (And you can bet they won’t say.)

Another ambiguity is that, even though your browser never sees the htaccess-as-such (it couldn't if you tried, unless you have the world's worst access settings), certain responses are cached. In particular, the browser “remembers” a 301 redirect. That's supposed to be one difference between the 301 and 302, though even then, browser interpretation may vary.

[robzilla]

Nope, the site is not https yet.

Could fix the problem. Apparently your cellular provider has some funky settings that interfere with communications. Encrypt the traffic and they won't be able to see you're sending or receiving cookies, so you'd be eliminating the first condition of your triad.

[explorador]

Thank you very much, encription sounds like a good way to go