So i'm creating a site that will add more rows to a table when you click on a button. Three tables, three buttons. I start randomly adding rows to the tables and then wham! there is a bunch of html garbage printing at the bottom of the page. Check the source and it looks like the HTML stopped printing to the browser.
I reset the tables, randomly add a few rows to the tables, everything is working fine and wham! there it is again. This time it stopped printing code at a different location.
I'm stumped at this point because its not in a place where there is any code being proccesses. Its in the middle of printing html. The page just stops running.
I drop a ticket to the server support to see if there is a problem with the servers that would create this and they can't recreate the problem.
I try it on three other computers here and the same thing happens. Now just for curiosity sake and good programmer testing we try it in Netscape and what do we find. Not a single problem! Flawless! It only happens in our version of IE 6 (newest updated version).
We've now come to the conclusion that there is a problem with IE and maybe a combination of that and the server that causes the page to stop loading. It seems to happen at the bottom of the page only, after the tables.

Could it be the speed? Could it be the browser? Could it be both? Is is something else? Has anyone heard of/seen this type of problem before?

Is there a way to maybe speed up the processing of CGI? Is using includes faster then loading the code in the same page?

Chalking up another headache to Mr. Gates,

David

: Could it be the speed? Could it be the browser? Could it be both? Is
: is something else? Has anyone heard of/seen this type of problem
: before?
In my experience, it tends to always be the *script*. No, it's not what you wanted to hear, but I know when I've gone chasing obscure things like this, it normally comes back round to an (often quite dumb) bug in the script.

If you're spitting out rows with no table tag around them, IE will render the data as a load of garbage. Netscape will say "what the heck is that? it's got no table tag" and display nothing. Different rendering engines, different results. It seems fairly likely it's your CGI based upon what you've said.

: Is there a way to maybe speed up the processing of CGI? Is using
: includes faster then loading the code in the same page?
Includes as in SSI? You're probably faster using one CGI than using many SSIs, if that's what you mean. You might also want to consider using mod_perl, which embeds Perl in the web server so your scripts run faster. In return, you have to promise to write your scripts well. If they don't run with warnings and/or use strict then you may well run into weird problems. Even if they do you may still run into weird problems. <grins>

What is it doing that takes so long, anyway? There may be a better algorithm.

: Chalking up another headache to Mr. Gates,
Not sure we can blame him for this one just yet.

Jonathan

###
for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
(tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
/(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");

: : Could it be the speed? Could it be the browser? Could it be both? Is
: : is something else? Has anyone heard of/seen this type of problem
: : before?
: In my experience, it tends to always be the *script*. No, it's not what you wanted to hear, but I know when I've gone chasing obscure things like this, it normally comes back round to an (often quite dumb) bug in the script.
:
: If you're spitting out rows with no table tag around them, IE will render the data as a load of garbage. Netscape will say "what the heck is that? it's got no table tag" and display nothing. Different rendering engines, different results. It seems fairly likely it's your CGI based upon what you've said.


Yah, this is most likely something with the script. I just don't get how it would all of a sudden stop running in the middle of a print ""; where its just HTML and no code and in random locations.

As well, I have the same version of IE at home and the problem isn't happening there, just here at work.

The reason for the garbage at the bottom is what you are saying, its missing HTML that it needs to complete the table and shows up in the page. The thing is, there is more information below that and in Netscape everything is showing up. If it was doing the same thing in Netscape as it is in IE where there is no more HTML being printed it wouldn't show the rest of the page but it is.

Only in IE and only here at work (or so it seems) is the information being sent to the browser to show the HTML stopping.

But you know what, its not happening today so maybe, whatever it is that was causing the problem has gone away and to never return! haha

I have heard that there is a very fine line between sane and insane. I think I have found that line =)

David
:
: : Is there a way to maybe speed up the processing of CGI? Is using
: : includes faster then loading the code in the same page?
: Includes as in SSI? You're probably faster using one CGI than using many SSIs, if that's what you mean. You might also want to consider using mod_perl, which embeds Perl in the web server so your scripts run faster. In return, you have to promise to write your scripts well. If they don't run with warnings and/or use strict then you may well run into weird problems. Even if they do you may still run into weird problems. <grins>

I was thinking along the lines of another file that holds some subs or variables but now that I think about it that would probably take longer calling stuff from another file.

:
: What is it doing that takes so long, anyway? There may be a better algorithm.
:
: : Chalking up another headache to Mr. Gates,
: Not sure we can blame him for this one just yet.
:
: Jonathan
:
: ###
: for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
: (tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
: /(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");
:
: