|too much? too little?|
Once and it's a fluke.
Twice and it's odd.
Three times and you have to investigate.
Here is the whole package. For reasons beyond my control, it is placed in the body of the document. (Inside a table cell, at that. Ugh.) The last few lines-- with explanation-- will seem irrelevant, but I think they're close to the core of the problem.
newstring = '<img src = "http://www.example.com/pictures/smallgifs/dot7' + pagenum + '.gif" width = "1" height = "1" alt = "">';
document.getElementById("clicker").innerHTML = newstring;
document.write ('<span id = "clicker"></span>');
<p style = "margin-top: 6em; text-align: right; color: #666695; font-family: sans-serif;" onclick = "showClick(5)">qaijjaanngilaq?</p>
<img src = "http://www.example.com/pictures/smallgifs/dot1.png" width = "1" height = "1" alt = "">
<img src = "http://www.example.com/pictures/smallgifs/dot1.gif" width = "1" height = "1" alt = "">
All gifs rewrite to a single file that expires instantly. All pngs rewrite to a file that lasts 24 hours. When user visits page, gif and png both load up. Each time they return or reload, a fresh gif dot shows up in logs.
The "onclick" business was added on a whim. It is hardly ever used, but works as intended: Request for /dot7x.gif shows up sporadically in logs, typically a few seconds after the first two.
Except that sometimes... instead of /dot7x.gif, logs show a request for /dot7 and that's all. This would seem to mean that
newstring = '<img src = "http://www.example.com/pictures/smallgifs/dot7' + pagenum + '.gif" width = "1" height = "1" alt = "">'
stops at the first close-quote, so
newstring = '<img src = "http://www.example.com/pictures/smallgifs/dot7'
<span id = "clicker"><img src = "http://www.example.com/pictures/smallgifs/dot7</span>
... which, I guess, shows how forgiving browsers can be. I have no idea what happens to the rest of the page, which contains approximately eight gazillion more tables containing all kinds of text. You'd expect it all to disappear, thanks to that unclosed quotation mark, but cursory experimentation suggests it doesn't.
Very, very close study of logs reveals that:
#1. There is no unifying feature among the users that this happens to-- browser, OS, IP etc. So that excludes browser add-ons and similar.
#2. If it happens to someone once, it happens every time.
#3. The request is concurrent with the two built-in requests, meaning that the user's browser is trying to execute the function on its own initiative.
#4. In spite of the different IPs-- right up to A block-- all three groups of events come from the same ISP. Size and location of ISP mean that this cannot be coincidence. Other users of the same ISP are unaffected.
Finally: At an earlier stage, I had two versions of the clickable paragraph. One, without the "onclick" element, was in a <noscript> section. The other, including "onclick" element, was inside the <script> section. The first occurrence of /dot7 alone came after I simplified by using the same text for everyone. But I don't have any hard evidence that this triggered the problem.
And hence the thread title. At first glance it looks as if the browser petered out halfway and didn't finish what it was supposed to do. But on closer inspection I think it's doing more than it's supposed to do.
? ? ?
Are you sure it's not a (transparent) proxy trying to preload stuff ? And not being intelligent enough?
(do some packet dumps, look at the ttl (it's an indication of how many hops the packet that arrives has passed))
Is it a satellite ISP ? They do very "funny" things with protocols to get over their 1/3 sec additional roundtrip time due to hthe signal having to go 4 time the distance to the geosync orbit.
Oh try to hide the string "http://www.example.com/pictures/smallgifs/dot7" by "calculating" it a bit more in the script
and then using them in the reverse order
or pagenum contains a space or quote or something odd ?
Exactly that would happen if the variable "pagenum" is undefined or null, would it not? Sure it has a value always?
I would suspect some sort of pre-fetching issue, where the browser (or possibly a browser add-on, or possibly some proxy server between the browser and your site) is parsing the document for URLs and attempting to load them under the covers. But check your document for calls to showClick to make sure they all have valid input. You could validate the input (pagenum) to make sure it's not undefined or null, and just return from the function if it is. If you do that and you still see these requests, then it's not a functional problem and is more likely not an actual user that's making the request.
|Exactly that would happen if the variable "pagenum" is undefined or null, would it not? Sure it has a value always? |
That's what I wondered about. If showClick is called in the intended way, it will always have a numerical value, explicitly identified as 1 through 4. Even 5 doesn't occur in real life; I just use it in my test page so I can pull it out of logs more easily. But if the browser is trying to call the function on its own, then no value has been passed to it. I guess a "null" or "undefined" value doesn't count as an unequivocal error, so the function still executes.
|You could validate the input (pagenum) to make sure it's not undefined or null |
Yes, that seems like the easiest escape route.
if (pagenum != 1 && pagenum != 2 ) ... et cetera.
Solves the problem of "how to prevent it" even if it doesn't answer the underlying "why" ;)