It is barely working for me.
IndyQ site broken?
- Thread starter maxeypad2007
- Start date
Working for me http://www.indyq.com/
Some smoking hot deals on there for cases right now. Roy is moving out older inventory to make room for new stock and has dropped the prices way down.
Some smoking hot deals on there for cases right now. Roy is moving out older inventory to make room for new stock and has dropped the prices way down.
click a few links and see what happens
The pages are opening fine for me. Post a link that is malfunctioning for you and then we can all compare our results.
The site's always been a little inconsistent for me. Sometimes it lags a lot.
Yeah it's a little buggy sometimes for me too. I don't know if it's the host or the coding. Roy recently changed the whole thing and that makeover had some issues.
But for now it appears to be working for me just fine.
Roy is gearing up for
Black Friday Sale!
Black Friday Sale!
Go to home page then click on Bender to see those cues. Then click on the John Barton Link and the website goes into La-La Land.
Worked fine for me. http://www.indyq.com/cases/barton-JB/index.html
the links on the right and left should be the same on every page. Those are permanent navigation links that don't change as you go through the site.
Maybe you mean la-la land as in a page full of rocking cases?
Yep...the www.indyq.com site is timing out for me and won't load. When I click on the link provided directly to the Barton cases, the page loaded, but with less than half of the images loading.
Recommendations for web-browsing best practices
John:
I just tried the site, and it literally SNAPS UP on all five of my browsers -- Internet Explorer, Firefox, Google Chrome, Apple Safari, and Opera.
TO EVERYONE: stop using "www" ("dubya dubya dubya") in URLs. It is not necessary to go to a website by placing "www." in front of the domain name. Want to go to IndyQ? Just type in "indyq.com". Want to go to AZBilliards (the main website, not the forums)? Just type in "azbilliards.com".
In fact, if you *do* type in "www." in front of the domain name, YOU ARE CAUSING TWO DNS QUERIES (instead of just one) just to resolve that website to an IP address.
For those using Windows, here's proof:
Notice in the above example, the commands I type in are red, and the pertinent answerbacks are in blue. Notice that when I query for "indyq.com" I get a direct IP address. Ask a question, get a direct answer -- bang, bang.
But when I query for "www.indyq.com" I get a CNAME record (canonical name) that points to indyq.com -- which your PC/Mac/iPad/whatever then has to issue *another* DNS request to resolve, to ultimately get the IP address.
Some firewall, intrustion detection/protection (IDS/IPS), and content inspection products either have problems with -- or just plain flag as anomalous activity -- recursive DNS queries like this. This especially happens when some updates have been applied to them recently that "updates" that product's behavior.
Recommendation: stop using "dubya dubya dubya dot" in front of URLs when you want to go to a website (unless you have good reason to, like in some very rare instances where "www" doesn't point to the same place that the raw domain name points to). I know we're either creatures of habit, or else we want to commemorate George "Dubya" Bush everytime we visit a website (evil grin for severe sarcasm), but now's a good time to start adopting web browsing best practices.
-Sean
John:
I just tried the site, and it literally SNAPS UP on all five of my browsers -- Internet Explorer, Firefox, Google Chrome, Apple Safari, and Opera.
TO EVERYONE: stop using "www" ("dubya dubya dubya") in URLs. It is not necessary to go to a website by placing "www." in front of the domain name. Want to go to IndyQ? Just type in "indyq.com". Want to go to AZBilliards (the main website, not the forums)? Just type in "azbilliards.com".
In fact, if you *do* type in "www." in front of the domain name, YOU ARE CAUSING TWO DNS QUERIES (instead of just one) just to resolve that website to an IP address.
For those using Windows, here's proof:
C:\TEMP> nslookup -type=any indyq.com.
Server: [...deletia...]
Address: [...deletia...]
Non-authoritative answer:
indyq.com internet address = 216.231.132.210
[...deletia...]
C:\TEMP> nslookup -type=any www.indyq.com.
Server: [...deletia...]
Address: [...deletia...]
Non-authoritative answer:
www.indyq.com canonical name = indyq.com
C:\TEMP> _
Server: [...deletia...]
Address: [...deletia...]
Non-authoritative answer:
indyq.com internet address = 216.231.132.210
[...deletia...]
C:\TEMP> nslookup -type=any www.indyq.com.
Server: [...deletia...]
Address: [...deletia...]
Non-authoritative answer:
www.indyq.com canonical name = indyq.com
C:\TEMP> _
Notice in the above example, the commands I type in are red, and the pertinent answerbacks are in blue. Notice that when I query for "indyq.com" I get a direct IP address. Ask a question, get a direct answer -- bang, bang.
But when I query for "www.indyq.com" I get a CNAME record (canonical name) that points to indyq.com -- which your PC/Mac/iPad/whatever then has to issue *another* DNS request to resolve, to ultimately get the IP address.
Some firewall, intrustion detection/protection (IDS/IPS), and content inspection products either have problems with -- or just plain flag as anomalous activity -- recursive DNS queries like this. This especially happens when some updates have been applied to them recently that "updates" that product's behavior.
Recommendation: stop using "dubya dubya dubya dot" in front of URLs when you want to go to a website (unless you have good reason to, like in some very rare instances where "www" doesn't point to the same place that the raw domain name points to). I know we're either creatures of habit, or else we want to commemorate George "Dubya" Bush everytime we visit a website (evil grin for severe sarcasm), but now's a good time to start adopting web browsing best practices.
-Sean
Last edited:
Was finally able to replicate the problem
Folks:
Actually, after I've been banging on the website a while, clicking links on it, and forcibly refreshing (via my browsers' Refresh button), I'm able to duplicate the problem. At first the site responded slower and slower, becoming more sluggish with every "product click" (and click of the web browser's Refresh button), until the site stopped responding for me altogether.
Unfortunately, from the client side, there's not much that can be seen for troubleshooting reasons. If the server chooses to stop responding (i.e. stop sending packets), the client has no idea why.
The only things I can think of, are the following:
1. There's some kind of web server software policy that is "caching" the client's IP address and automatically adding it to a misconfigured "bad client IP address" policy.
2. The web server itself is misconfigured -- perhaps there's a web server pool, and the members of the pool aren't sharing the load correctly. Perhaps some of the traffic is being directed to a member of the web server farm that is DEAD (i.e. crashed).
3. The firewalls and/or reverse-proxy servers in front of the web server farm are misconfigured.
Either way, to help troubleshoot this, we're going to need help from the web master, and possibly the co-location facility that houses the web server farm, to find out why this is happening.
I will be busy this weekend, but I'll try to offer my hand in any troubleshooting if we can get the involvement of the above-mentioned personnel.
-Sean
Folks:
Actually, after I've been banging on the website a while, clicking links on it, and forcibly refreshing (via my browsers' Refresh button), I'm able to duplicate the problem. At first the site responded slower and slower, becoming more sluggish with every "product click" (and click of the web browser's Refresh button), until the site stopped responding for me altogether.
Unfortunately, from the client side, there's not much that can be seen for troubleshooting reasons. If the server chooses to stop responding (i.e. stop sending packets), the client has no idea why.
The only things I can think of, are the following:
1. There's some kind of web server software policy that is "caching" the client's IP address and automatically adding it to a misconfigured "bad client IP address" policy.
2. The web server itself is misconfigured -- perhaps there's a web server pool, and the members of the pool aren't sharing the load correctly. Perhaps some of the traffic is being directed to a member of the web server farm that is DEAD (i.e. crashed).
3. The firewalls and/or reverse-proxy servers in front of the web server farm are misconfigured.
Either way, to help troubleshoot this, we're going to need help from the web master, and possibly the co-location facility that houses the web server farm, to find out why this is happening.
I will be busy this weekend, but I'll try to offer my hand in any troubleshooting if we can get the involvement of the above-mentioned personnel.
-Sean