Random connection with URL???

[MickeK]

This quest doesn't relate to any code problem even if it has to do with web-communication in general. I believe that there are folks in this forum with a lot more knowledge of URL's and server behaviour than me. I've learned that computers allways is logical and sooner or later you find what causes a problem. At the moment I have such a problem (that doesn't seems to be logical) and I just have to pin point what might generate it.

What happens is that the browser don't display some pages on a first attempt. Doesn't matter if the URL is called by typing the address or addressed from links or bookmarks. On the first attempt the browser displays the standard error message of "page can't be found on server".

HOWEVER...

...reloading the same URL (sometimes once is enough sometimes it takes a couple of reloads) will display the page - so it IS on the server after all :). From that on it's no problem at all to navigate within the pages of the site but if I leave the it, or close the browser, the same problem repeats next time. It's not logical to me at all. Either there´s a page on the URL or not. I can guarantee there´s no scripting errors it's just a problem of get in contact with the server. Anyway, no script are interpreted as the browser "can't find the page".

As this happens especially on the URL's of my own site (but CAN happen on other URL's as well) I contacted the support of my UNIX server supplier. We tested runtime and they could see my rejected attempts. They couldn't give me any hint of what might cause this but vaguely refered to my own system. IOn their words this cannot be a problem at their end. My hope is that anyone here can deliver a more straight answer.

I have to be certain when communicating my URL to customers. If they have the same experience they will probably not try more than once to load the page. I plan some marketing actions but don't dare to take that step before I have some clue about what generates this behaviour.

So, can it be some setting in my OS or anything locally on my computer? As three browsers behaves the same I've excluded any browser setting. I'm stucked trouble shooting and haven't experienced something like this before. Typically it happens more often (t.i. "mostly") when addressing the URL's of my own so I'm still a bit suspicious with the server I use. Hopefully you can help me out. Thank's in advance.

My best
Micke

[molendijk]

This is probably caused by a script on your site that loads too late, or gives a wrong message to the server before it's finished loading.
I remember having this problem in the past. I removed all the scripts, and everything was OK (except that the scripts couldn't work). Then I successively re-inserted my scripts until I discovered what script was causing the problem.
What puzzles me is your remark about foreign URLs not loading. How do you load them? Via javascript on your own site? If that's the case, and if the foreign URL doesn't load, then the problem must be on your end.

[MickeK]

Hi molendijk and thank's for your reply. My first reflection was some php-code with require statements that is first rows of the scripts to a lot of my pages. Can't be those though as I first checked a index.php page that very often has to be reload as it most often is my start point of browsing the site. The code of that one has no php-code at all except from an include statement for the footer. The first rows is standard startup code generated by Dreamweaver and I can't see anything special about it.

Even if you probably can't read the swedish page as such you can check the code from your browser. Go to:
www.imatri.se to see if you can find anything that might send a "wrong message" to a server. I really don't understand how it can send a wrong message first and then be accepted the next time but as I said, I'm no wizard on server communication.

Anyhow this index -page is very straight forward (just the lines below "LOWER SECTION STOP" is generated from the include statement. If your browser loads it without problem it point at something is wrong in my own environment but I just can't see what in the OS, Firewall or whatever that might cause it?

To clarify a bit I have a lot of subpages on the site of my company with slightly different scripts. I also host a couple of other domains in subfolders and to see anything consequent here it is that it doesn't matter what of those pages (index-pages or sub pages) I try to address from the browser. All of them generates a "can't be found on server" at the first attempt.

The thing that puzzled you might be a misunderstanding of my attempts to describe what's happening. I was refering to a simple visit to other web-pages from the browser. Sometimes I get this kind of need for a re-load on other sites as well but normally I have no problems with other sites. But any of the pages of my site, or other domains in subfolders of the file structure on my server, seems to generate this most irritating behaviour. I have a few java-scripts on some of the pages, but the "error" occurs on all of them so it don't seem to be a problem.

Another thing is, that I said, when one of the pages are displayed after a re-load I can browse to any page on the site without problems. It just the first "fresh" attempt to address the site that causes trouble.

So, I'm still confused and still can't find any better logic conclusion that there´s something with that particular server. But I've told that that's impossible by my supplier. On the other hand it isn't the first time you get such a message as a customer. Especially as you often can't rely to special competense in server tech ;).

I hope this thread will take me closer to an explanation of this. I can live with an unsolved problem in my local environment as long as the rest of the world can visit mine and my customers pages. Those are subdomains to mine so it's crusial so to speak...

[Beverleyh]

I don't think there is much that we, as outsiders, can troubleshoot once the page is displayed in the browser - we can view source code but as we can only do that once a page has been served successfully, we'd only be looking at the good, final product. What you need to troubleshoot is the page generation - before it even reaches a browser - and that is something that can only really be done from the server side.

I'm guessing that the pages are being generated by a server-side language such as PHP? As Arie suggested in his post, maybe an included script or configuration file isn't loading/compiling correctly at runtime? My first thoughts are that a header or gzip decompression is failing? or maybe a file isn't compiling quickly enough on first load (memcache/d)? Is your website querying a database? Might be related to that.
These are all just wild stabs though. A good place for you to start would be with your error logs - have a look there to see what messages are being recorded and then hit Google.

What you could also do is recreate your website locally using WAMP http://www.wampserver.com/en/ and/or XAMPP https://www.apachefriends.org/ Build it up piece-by-piece until you find what is causing the problem. Once you know what is causing it you'll have a better time researching in Google. Similarly, have you got access to another web host where you can try to recreate your site? Depending on what resources you need, you might be able to sign up for a free account somewhere.

Another option could be to post a job request in the general paid help forum http://www.dynamicdrive.com/forums/forumdisplay.php?30-General-Paid-Work-Requests - if you're comfortable with having another developer work on your server, maybe you could get somebody with more server experience to work in the backend with you, under an official working agreement.

[molendijk]

Hi Micke,
By 'wrong message' I ment 'incomplete(d) message'.
I examined your source. The comment sections should end like -->, not like -------------------------->
So maybe there's an 'interpretation' problem somewhere on the road? Anyhow, try to fix that first.

[MickeK]

Hmmm... Can it be that simple molendijk? I've now updated all the scripts with that in mind. It seems to fix the problem even if I just tried a couple of times. As the error was a bit random I prefer to test for a day or two before I feel totally safe. But a big THANK's for information about that detail if it (as it seems) solve my problem. BTW a big thank you to Beverly as well. Very nice of you to add more info that might have helped. But PHP-code was not involved in all failing pages so the solution had to be something else. Probably my personal choice of structuring HTML comments is the source of the evil :).

Some month ago I decided to compose a standard structure to all my scripts to make it easy to follow and understand the code. Somehow I found it nice to devide script part with <!-- Comment -----------------> Well aware of that <!-- comment --> is the correct syntax I had in mind that ANY CHAR before the ending --> would just be included as a part of the comment and therefore not a subject of any interpretation. As everything seemed to work just fine except from the random need for re-loads I never would have guessed that was the case. Still it seems a bit odd that the interpretation as such sometimes signals "NO, this is not a web-page" and sometimes "OK, let's put out this even if it's not totally correct" but I hope it is the case and if so all my respect to you finding it.

So, I sure hop I don't have to come back to this. The relief would be great of one problem less to solve :). Have a nice weekend.

[MickeK]

SADLY... ...the HTML comments was NOT the problem. Still have random fails of laoding the page. I will try to follow Beverlys advides. As I don't use PHP and database query in all pages it has to be something else. I'll try with the error logs...

[molendijk]

There are still errors on your page that might cause the problem
You have two identical ids (id="wrapper") at different lines: 16 and 59
You have two identical ids( (id="leftCol") at different lines: 28 and 62
There should be a closing li-tag at line 43, so </li></ul>, not just </ul>
You start a p-tag at line 82, but you haven't closed it
You start a div-tag at line 59, but you haven't closed it.

[MickeK]

Thank's for pointing those errors out. You're totally right - except from the closing </li> that actually was there ;).

The question is if any kind of "sloppy" coding like this really might cause a server to totally reject an URL??? You miss a lot during development but usually detects it immediatly as the browser displays a corrupt page - not messages of "not found on server". The errors in code you found missed me as the page looked just right by co-incedence and I'm very surprised that the missing </div> didn't crash the layout.

Besides this I find the number of URL rejects at the moment in fact are very low compared to the weeks before. If it wasn't for one or two rejects the last couple of days I would have considered the problems solved. After I edited all my HTML-comments and took away every example of -------> endings due to molendijks recommendations. Still I was surprised that such an ending wasn't allowed (or perhaps is after all?). To me EVERYTHING between ANY <!-- --> would be ignored. Anyhow, as far as testing goes the rejects of the URL are fewer. Most irritating that it actually DID reject once or twice and that way signals that I didn't found the solution after all.

My personal "logic" around the task is close to what Beverleyh wrote in posting above. If a page HAS been served successfully the source code probably can't give a hint of what's REALLY the problem regarding the "page not found" problem. What it can be is then more a task of trying to follow error logs and I haven't had the time yet to do so. At the same time things have turned to the better after fixing all HTML comments. I really hate when you experience inconsequences working with computers as the only thing I know for sure is that computers allways are consequent and follow instructions. I have doubt that fact thousands of times but sooner or later found some logic explanation.

The hours tends to run fast when trouble shooting and at the moment it seems to work ok, if not with total stability, so I'll have to let it rest and work. Very thankful to any inputs around my reasoning as it really helps.


A bit off topic of all this (but perhaps not) molendijks note of me using identical IDs to my divs makes me wonder of another thing. I read about what differs an ID from a Class in css. I had then already experimented a bit and used an ID with an without a declaration of a Class. That way the page in question (the one you've looking at) did present the layouts I intended to do. So I found it a working concept in css-writing. I then read that an ID only could be used ONCE on a specific page. As my page seemed to work anyhow my guess was that the IDs wasn't "identical" as one had a class declaration the other one hadn't.

To correct (if necessary) those "identical ids" I have to do alternate IDs and a bit more over a couple of pages. As it seems to work fine as they are I hesitate to do it right now. I will if it has anything to do with the interpretation of code but then again I'm not too sure that code from a "rejected" page will be interpreted at all???

I rest my case for now. Sometimes it seems like you're the only one experience all odd kind of computer failures. Such as nobody ever has experienced. And it's no surprise anylonger as it has happened now and then during the years and made work weeks in vain to get it right. Know what I mean by that? ;)

[molendijk]

Your code may still function fine with multiple identical IDs, but it will put more stress on the DOM.

Using identical IDs together with different classes equals to just using the classes (presuming the specifications for the classes do all the work they are required to do).

It occurred to me that a 404 error may result from a browser's cache not being emptied, i.e. from something that was the case in the past ON YOUR COMPUTER AND IN A GIVEN BROWSER. So you may want to verify whether the 404-problem persists:
1. after emptying your browser's history,
2. with other browsers,
3. on another computer.

If there's no problem in cases (2) and (3), there's most probably no problem at all.