We are an online business providing web content to our customers. We
have started seeing some problems where customers are getting a blank
screen when they view some of our pages. We have eliminated the
possibility that it is a server side issue, as we know the pages are
always being generated and served, apparently successfully. We also
have found that these particular pages are all over 500kb of HTML
(that is, the images aren't weighing it down--and while that seems to
be an approximate cutoff point, the number is not nailed down). The
bulk of the HTML content--and that which is relevant in terms of
changing the pages' size--is shallowly-nested tables with CSS
formatting. So far we've only seen it on Internet Explorer 6--as far
as we know. 'Lighter' versions of these pages seem to work fine when
we give them to customers; that is, a smaller volume of the same
content formatted the same way seems to work fine. There is no
correlation between bandwidth and the pages not loading--these
customers have high-speed internet connections, those we've asked. It
would appear that this is a browser rendering issue, but we are unable
to find any information about it on the web. Can you tell us why
these pages are not loading? |
Clarification of Question by
ddellacosta-ga
on
29 Jun 2004 14:20 PDT
Oh--and to clarify, we are not able to reproduce this. We have people
in our office using the same systems and they do not have this
problem. So it is not a consistent issue with users across the board.
|
Request for Question Clarification by
larre-ga
on
29 Jun 2004 14:33 PDT
If it's a browser issue, I'm afraid it'd be nearly impossible to
troubleshoot based on description alone. This isn't a "known" problem
(e.g. something documented as related to page size). You'll probably
need to list a code example or provide a link to a problem page in
order to track down specifics.
A list of user characteristics would also be very helpful. I can think
of a dozen reasons why a phenomenon might affect an individual user,
but all are related to individual browser settings, surfing helpers
such as toolbars, cookie, spyware and pop-up blockers, proxy settings,
or OS/Firewall/AV programs and settings.
---l
|
Request for Question Clarification by
aceresearcher-ga
on
30 Jun 2004 06:00 PDT
Greetings, ddellacosta!
Can you provide the URL of one of the problem pages?
Thanks,
aceresearcher
|
Clarification of Question by
ddellacosta-ga
on
30 Jun 2004 07:48 PDT
Hi folks,
I'm afraid I'm under the constraint that we will not post the links to
this publicly, but if you can give me an email address I'll gladly
send it to you.
As far as a list of user characteristics, that's all I have for
now--but I'm working on compiling some more. If you can tell me
specifically what you might be most interested in that would help as
well.
Thanks!
|
Request for Question Clarification by
aceresearcher-ga
on
30 Jun 2004 08:15 PDT
Unfortunately, the Researcher's Terms of Service do not permit us to
exchange contact with Customers outside of the Google Answers site. Is
it possible to post a URL written backwards (so that it won't be
indexed by the Googlebot), or is that also not allowed? It will be
extremely difficult to troubleshoot without seeing the actual code.
Thanks,
ace
|
Clarification of Question by
ddellacosta-ga
on
30 Jun 2004 11:43 PDT
Okay folks, I've written a simple reversal/rot13 perl one-liner.
Mostly 'cause it was fun. ;) But this is pretty easy to use: just
stick the links where I wrote "text to convert here," and run it on
the command line. Should work on most UNIX variants, assuming Perl is
installed, and with ActiveState perl on Windows.
perl -e '$rot13 = $ARGV[0]; $rot13 =~ y/A-Za-z/N-ZA-Mn-za-m/; print
reverse($rot13) . "\n";' "text to convert here"
If you don't have perl available, but you can figure out how to
reverse it easily, here's a web-based rot13 converter:
http://retards.org/projects/rot13/
This link is an example of a lighter page that we don't get complaints about:
abvtre=]rclGrhyni[CXEBJ&5=]rhyni[CXEBJ&ergfvYobw=]1[DXEBJ?yzguc.tavgfvy_obw/zbp.erqqnyfrynf.jjj//:cggu
...and this is a heavier page, one that people have difficulties with:
8=]fxrrJzha[CXEBJ&abvtre=]rclGrhyni[CXEBJ&2=]rhyni[CXEBJ&ergfvYobw=]1[DXEBJ?yzguc.tavgfvy_obw/zbp.erqqnyfrynf.jjj//:cggu
I'll get back to you with more details as soon as I get some feedback
from our users.
|
Request for Question Clarification by
larre-ga
on
30 Jun 2004 12:07 PDT
Thank you. This is helpful. I will begin comparison, looking for key
elements that might conflict with certain browser characteristics.
---larre
|
Request for Question Clarification by
larre-ga
on
30 Jun 2004 14:39 PDT
A few more questions...
Is it the same users affected by the problem over and over, or does it
rotate among users? Are affected users -always- unable to access the
longer pages, or does behavior vary, the pages are accessed sometimes,
other times they cannot ? (looking at caching and data flow issues)
Page header handling -- does the script/program serving the pages
adjust the headers any way? (looking at firewall and possible proxy
issues)
We're looking at all North American users here, are we not? (looking
at possible browser version/build issues)
Thanks ---larre
|
Clarification of Question by
ddellacosta-ga
on
30 Jun 2004 14:49 PDT
Okay, hopefully this will answer the questions:
1) Every customer who has this problem seems to have it consistently.
In fact I have server side logs showing a customer hitting a page over
and over, apparently in an attempt to get it to work. So, I'm
guessing the other poster's question about reloading has an answer of
"no" as well.
2) We are not doing anything to the headers that I know of. We are
using mod_deflate with Apache, I'm not sure if this is relevant or
not.
3) It is most probable that we are exclusively looking at North
American and probably U.S. users.
Let me know if there anything I can add.
|
Clarification of Question by
ddellacosta-ga
on
01 Jul 2004 08:36 PDT
Got some responses from a customer today:
1. Micro Intern. exp. (recent version... maybe 1 year old)
2. windows xp
3. cable modem
4. home
5. prolog ptd.net
6. yes, norton personal firewall, norton anti virus, norton system works
7. no
8. so get this... i just logged on to your site to try it again.... all
the regions in "browse jobs" loaded accept for "mid atlantic"... i was
clicking on the map... so maybe it just the link... although, i did get
it to load earlier today from the map...
Based on these questions:
what browser type/version (as specific as possible) are you using?
what operating system?
what type of connection (dial-up, broadband, etc.)?
at home, or corporate network?
who is your ISP, if applicable?
do you have a firewall installed?
do you have any other sort of 'add-on' browser software? (I'm not sure
if the customer answered this one or the next)
does the page render if you click the stop button?
does the page render if you reload
And the customer clarified a bit later by saying:
just as an fyi, i turned off the firewall, but the page still wouldn't
load...
|
Clarification of Question by
ddellacosta-ga
on
01 Jul 2004 08:37 PDT
Oh--and note that we've shrunk our pages at this point, the heaviest
ones are around 500k still though. And that seems to be the ones that
people are having trouble with--still the 'heaviest' pages.
|
Clarification of Question by
ddellacosta-ga
on
01 Jul 2004 08:45 PDT
Another response:
what browser type/version (as specific as possible) are you using? IE
6.0.2800.1106.xpsp
what operating system? XP
what type of connection (dial-up, broadband, etc.)? Braodband
at home, or corporate network? Homw
who is your ISP, if applicable? Optimum online
do you have a firewall installed? yes
do you have any other sort of 'add-on' browser software? no
does the page render if you click the stop button? no
does the page render if you reload (I feel like this is answered already,
but...) no
if you have another browser(s) installed, does it work in that browser?
No other installed
Can you see any of these links? Yes- All are OK
http://www.blackmask.com/books15c/iliab.htm
http://www.blackmask.com/olbooks/yankee.htm
http://www.blackmask.com/books30c/mtmts.htm
http://www.blackmask.com/olbooks/canterbury.htm
http://www.blackmask.com/books10c/crsto.htm
(a brief explanation about the links at the bottom--we're trying to
establish some sort of correlation about the size and people's
inability to see the pages, so we found a bunch of 'big' pages
yesterday to ask customers to check out. So, as you can see, there
must be something specific in our pages which is stopping the
customers...)
|
Request for Question Clarification by
larre-ga
on
01 Jul 2004 15:59 PDT
Following research and testing on various configurations, I'm afraid
that the only conclusion I can draw is that size alone is responsible
for the page(s) not loading on various user systems. I can reproduce
server errors using just the HTML (not dynamically generating) the
page testing with a couple of older systems that are part of my own
network, if I set certain conditions, then overload caching ability.
I will be glad to detail findings for you as an official Answer, if
this information would be useful to you.
---larre
|
Clarification of Question by
ddellacosta-ga
on
08 Jul 2004 09:12 PDT
Hi larre, sorry it's taken so long to answer. Basically, if you have
some data that you think matches our problem set--that is, the size
breaks the browsers down at the same point that it seems to for us
(above 500k) and it uses the same (seemingly up-to-date) browser/OS
combination that we've seen, then I would like the data--however it
sounds like you've found perhaps different behavior than what we are
seeing. Let me know what you think. We have engaged in other tactics
at this point to meliorate this problem, but we would still like to
know the real issue if we can.
|
Request for Question Clarification by
webadept-ga
on
26 Jul 2004 19:33 PDT
Hi again,
I have been able to 'reproduce' the effect your clients are having
with these pages, by cutting down the cache size in my IE and setting
the IE to default settings. Starting at your front page then and going
through the map, I then run into the 'blank' page effect about 3 pages
in. So this could be a problem with the sucsestion of huge pages and
IE's tendancy to build up huge caches as well. Have your client clear
the cache in the Browser and see if that allows the page to load.
Another note I'll add in here from my work this weekend, is that I
created a test site using the html output of your website upto the
point I got the white out effect, and ran the test again. I wasn't
able to reproduce the white out with only HTML pages, that were not
rendered. So, it may be a combination of the heavy ladened cache and
the time wait for the pages from your server. I could not test the
time wait theroy in the time I had this weekend.
webadept-ga
|
Hi,
I know what your problem is here, and can tell you how to fix it, but
although the answer may be worth it to you, we normaly try to make an
answer worthy of the value of the question bid as well... and normally
I'm very good at putting lots of stuff in an answer to make it
'appear' worthy. But this time I don't know how to do that. Its a
simple problem with a simple fix and that's just the way it is.
Your HTML is using Character codes 128 to 159 (U+0080 to U+009F), and
since you are creating these dynamically they are also coming out in
binary format. This causes unpredictable results in the ability of
browsers to render the page. Even computers with the same OS, and same
version of browser will display these in different ways at times, or
show a blank screen at others. Browsers that see a blank page at one
url, while viewing a page with the exact same code as the one before
on the same website will suddenly be unable to see the page render. It
is bizzare, but a well known and well documented phenomena. What are
these codes? Things like the trade mark mark, and copyright mark and
stuff like that. Check the link I'm giving you for full documentation.
wow. I made a whole paragraph out of that.. I'm impressed. Basicaly,
take those characters out of there and your pages will load fine.
There is a util you can use to check your pages in the future if you
run into similar problems called Tidy, which may interest you, and
here is a link describing this problem.
Character Codes
http://www.psacake.com/web/0302-b.asp
By the way, very cool trick with the url's.. but the syntax for
reverse is off. Still, well done there..
thanks,
webadept-ga |
Clarification of Answer by
webadept-ga
on
14 Jul 2004 04:13 PDT
By the way, if you run tidy on the html of that hanging page, it hangs
at the end as well just before the end while trying to replace the
code you have there, the same way a browser would, and not show the
page.
webadept-ga
|
Request for Answer Clarification by
ddellacosta-ga
on
15 Jul 2004 09:00 PDT
Alright, I hope this is the solution, and it sounds reasonable. This
is difficult for us to test right away though, so let me ask a
question and make some comments, if you don't mind.
I ran tidy on one of these big pages. I did see some instances of
setting invalid character code 150. So you're saying that just one of
these is enough to confuse a browser and break the page for the user?
Any idea why the size correlation then?
I ran tidy and that seems like a good tool to check. I didn't see it
hang on any of the pages I tried though, but that's neither here nor
there.
And finally, what is wrong with my reverse syntax?? Works fine for me
when I run it. ;)
Thanks webadept, I'll get back to you on the payment when we've done
some testing to make sure this fixes our bug.
|
Clarification of Answer by
webadept-ga
on
15 Jul 2004 11:32 PDT
Let's see..
Yes, just one is enought. The random factor in this has driven many
poor soul to tears. So change your Copy Write code to © and what
ever else needs to be done to get those out of there.
Yeah.. I spoke to soon on the Tidy thing.. it didn't really make much
sense to me after I posted that, and found that if I ran it straight
it ran through there were no problems.. but if I used the -o switch
for output file it hung, which is still odd (??) I'm not sure why it
would hang, or what those codes would do to it to hang.. probablly a
coding error.. its not a browser <silly>
syntax for reverse is : reverse $thing to reverse not $thing reverse
.. at least in this part of the world ;-) wouldn't run for me. I tried
it because I thought you found something new :-) But, there's always
another way to do things.
I'm pretty sure this is your problem. So sure I answered the question,
and by all means, if you have questions, ask, that's why we are here
:-)
I do absolutly know the following. It's not the size. The basic HTML
is fine. The responce time from your server is well within reasonible
boundries. There's no 'bucking' happening with the images that I saw.
(You aren't using PNG's or JPE's right?.. I didn't check that.. silly
rabbit.. damn) A fast quick stress on your bigger pages showed no sign
of bottle neck through 4 seperate routes and forcing a bottle neck at
my router, still showed no sign of the problem you are describing with
the effect. Soo..
webadept-ga
|
Clarification of Answer by
webadept-ga
on
22 Jul 2004 12:59 PDT
Hi,
It is normaly a good idea to use the clarification button prior to
rating and closing a question. This gives the researcher the go ahead
to continue researching the question for you, and to find the answer
that best suits your needs.
Being as you are probably new to the service, no harm no foul, and
I'll look into this further for you, and find out what's causing this
page viewing problem.
Did you happen to note any of the problem client's IP addresses?
webadept-ga
|
Clarification of Answer by
webadept-ga
on
22 Jul 2004 13:13 PDT
Hey again,
This is kind of a long shot, but with some recent problems I had with
my ISP, I thought I would check up on the name we have up there. I'm
guessing, since you gathered the information, you've already looked
into it and found the number of stories I did, and, Optimum's policy
on filtering transmissions.
--"Cablevision prefers to advise Customers on inappropriate behavior
and any necessary corrective action. However, if the Power to Learn
Internet Access or the Services are used in a way, which Cablevision,
in its sole discretion, believes violates this Agreement, Cablevision
may take any responsive actions it deems appropriate. Such actions
include, but are not limited to, temporary or permanent removal of
content, cancellation of newsgroup posts, filtering of Internet
transmissions, and the immediate suspension or termination of all or
any portion of the Power to Learn Internet Service." --
Is there a corrilation with any of the other customers with this
problem. I personally had to setup my own DNS for my server because of
radom blocking of websites and filtering of transmissions, due to
"other accounts" so they said.
Anyway, it was a thought. I'll get into this seriously Friday evening.
Anything else you have discovered that might help, just post it and
I'll go over it.
thanks,
webadept-ga
|
Clarification of Answer by
webadept-ga
on
22 Jul 2004 13:20 PDT
Just one other thing..
You mentioned that you tested this by creating static pages and having
the client look at them in that form. Did you test as well with the
same page on a different domain? Try getting a free blog site or a AOL
friend page or something and post the page there. Someting not on or
in your IP nieghborhood, something far away. I have an IP address I
can post it to if you can't find something. I think at this point, we
should try to find out if it is indeed the page. If my first answer
was not the problem, then I personally don't think the page itself has
anything to do with this. I've seen much larger pages, on much smaller
bandwidth. But that is the first step, is the the page or not?
webadept-ga
|
Clarification of Answer by
webadept-ga
on
22 Jul 2004 16:15 PDT
Hey there, yet again,
You said in your post down here
---"our customers static versions of the 'broken' pages (pages with
invalid characters) and 'fixed' pages (removal of the invalid
characters) and our customers were able to see *all* the pages. So,
this is not the answer."---
You meant to say they were NOT able to see all pages ... yes(??)
Because a client able to see both, is not a test against the answer.
As the White Papers on the problem say, this is a radom error,
happening and not happening without traceable pattern. So being 'able
to see' is not a test. If the 'clean' page is still unable to be seen
by those that could not see the normal page, then that would prove
against this answer. Just want to clarify on that.
I've found a 'possible', but need to run some tests. I'll get back to
you once I've been able to confirm with a better source than the one
that lead me too it.
webadept-ga
|
Request for Answer Clarification by
ddellacosta-ga
on
26 Jul 2004 09:37 PDT
1) Sorry, I thought I had requested enough clarification. But I am
new to google answers, so I apologize if I've committed some faux pas.
2) Seeing as we asked some of our customers who had previously had
problems with the pages to view multiple pages, both with and without
the invalid character codes, and they could see *all* the pages just
fine (and by the way, I did mean what I said--they *could* see all the
pages), this seems to me to be a pretty direct refutation of the
conclusion that invalid character codes are the problem. I don't see
how this is not the case...and the answer that this is some sort of
'randomized' behavior just doesn't cut it, I'm sorry, considering the
fact that our customers are *consistently* having these problems.
There's obviously something systematic going on here.
3) Whether or not the size is *the* problem--which I agree with you,
it probably isn't--there is a correlation between the size of the page
and the problems that customers have. This is definitely a factor to
be considered, as it is consistent.
|
