Internet Explorer - www doesn't find

  • Thread starter Thread starter IT-Tech
  • Start date Start date
I

IT-Tech

I am having an issue where I can go to any site with an
address of http://site.site.com, but I cannot go to any
www.site.com sites. I get a "Page Cannot be displayed"
Error. I have checked the security settings. Zone Labs is
installed, but doesn't seem to affect it. It does this
every now and than, not all of the time.
Thanks,
IT-Tech
 
IT-Tech said:
I am having an issue where I can go to any site with an
address of http://site.site.com, but I cannot go to any
www.site.com sites. I get a "Page Cannot be displayed"
Error. I have checked the security settings. Zone Labs is
installed, but doesn't seem to affect it. It does this
every now and than, not all of the time.
Thanks,
IT-Tech
Click to expand...

See
Dealing with Unwanted Spyware, Parasites, Toolbars and Search Engines
http://mvps.org/winhelp2002/unwanted.htm
 
Welcome to the "page cannot be display" error that is occurring on IE.
Everyone is getting this. Do a google search and you see, you are not
alone.

While there might be other reasons, we found it to be a BUG in IE.
Obviously, Microsoft are not going to acknowledge this until it is FIXED.
It may be related to recent security buffer overflow related issues
addressed in:

MS03-042 - Buffer Overflow in the Windows Troubleshooter
ActiveX Control Could Allow Code Execution (826232)

MS03-045 - Buffer Overrun in the ListBox and in the ComboBox
Control Could Allow Code Execution (824141)

Go to http://www.winserver.com/public/code/html-ietest4 to repeat this
problem at WILL using a FORM with posted data. The page explains what you
need to do. See if you can repeat this "Page Cannot be Display" error with
your copy of IE.

Some people get the PAGE CANNOT BE DISPLAY error, while others get a strange
refreshing of the page where the page reset to zero field values.

Based on my analysis with packet sniffers, in short, what is happening is
the IE is not properly supporting RFC 793 related to lingering socket
closures.

To workaround the problem, Web servers will need to throttle the sending of
pages and delay the closing of the socket. In other words, when a page
is sent, the browser is thinking that the connection was lose, hence it gets
show this error, when in fact, it was basically not reading the data from
the socket to completion.

This doesn't happen with any other web browser.

This is explained in directly MSDN documentation on how to properly
gracefully read a closing socket:

"
To assure that all data is sent and received on a connected socket before it
is closed, an application should use shutdown to close connection before
calling closesocket. For example, to initiate a graceful disconnect:
1.. Call WSAAsyncSelect to register for FD_CLOSE notification.
2.. Call shutdown with how=SD_SEND.
3.. When FD_CLOSE received, call recv until zero returned, or
SOCKET_ERROR.
4.. Call closesocket.
"

It seems the IE BROWSER is not doing step #4 correctly.
 
How about not taking the easy route and blaming viruses? huh?

How about really reading what people are reporting ALL over the internet
about this ludicrous PAGE CANNOT BE DISPLAY problem? Its a real problem.
Have you even investigating this? Have you read my posting? Have you even
tried the URL which shows how to repeat the problem with IE? Did you even
#$%@ing try?

Geez! Blaming a virus! Pleeeeeeeeeeze! And you are a MVP?

I'm sorry, but there are TONS of reports of this going on and I SEE
absolutely nothing from MICROSOFT that explains whats going on.

----
 
Oh, I doubt "they" are ignoring me. You aren't

Look, if you have something to contribute, do so. Otherwise, don't hide
behind a fake name and don't let me be a reason for your existence.

have a good @#$%ing weekend.
 
HEy all I am having the same problem where I can't get any home page with
www.page.com to open, but if I go to goggle or even do a search thru the
built in microsoft search then click the page will open up. I have scanned
for viruses and also used adaware to scan nothing on my system. I did
recently install the new security downloads amd also installed office 2003
recently. Can anyone help with this problem?
 
Hi Hector - FWIW, I was unable to repeat your results with any size I tried.
This was using a fully updated IE6 under Win2kProSP4, Sun Java VM. I wonder
if you could please post the test conditions under which you experienced
this (repeatable) error? Please note your OS and SP level, all hotfixes
(the Update Versions stuff) shown in IE6, Help|About, and which Java VM
you're using. Thanks.

--
Please respond in the same thread.
Regards, Jim Byrd, MS-MVP



In
 
Thanks Jim for the feedback.

We have a new test suite #5 that is using a new web server with adjustments
is at:

http://www.winserver.com/public/code/html-ietest5

It is now running and being tested by beta testers with success so far.

The adjustments were:

- Adding a small Sleep() delay before the socket is shutdown and actively
closed (active as opposed to passive), and/or

- Send throttle speeds.

What was discovered is that IE (variations there of) is not completely
reading a socket that is closed.

A throttle on the send may solve the problem but not all the time depending
on the user's connection performance, reliability and whether it is equal
speed on both sides (ADSL vs. SDSL vs. T1 vs. DIALUP)

No other browser exhibited the behavior, including a small client I wrote to
send the POST
request and get the results.

Keep in my that we sell dial-up and intranet hosting software in the
vertical market. These issues start with customer reports. So there are many
variations of setting. At least 50+ people (including testers) ran test #4,
with similar mixed results which I attributed to how they are connected to
the internet. The test logged the results so I was able to see that IE was
reissuing the request in many cases.

Playing with send throttles/bandwidths and/or delay closures help address
the issues until I zeroed in on a sleep value that worked for all.

The only thing left is that I am not comfortable using a "sleep()" on the
close. This is not the real solution, so it is still an open issue.
Technically, It can be understood how this pre-empting the thread will give
the socket layer a more time to perform its lingering shutdown and close.

According to the MSDN doc, IE should be doing something similar to this
documented logic for the shutdown() socket function:

"To assure that all data is sent and received on a connected socket before
it is closed, an application should use shutdown to close connection before
calling closesocket. For example, to initiate a graceful disconnect:
1.. Call WSAAsyncSelect to register for FD_CLOSE notification.
2.. Call shutdown with how=SD_SEND.
3.. When FD_CLOSE received, call recv until zero returned, or
SOCKET_ERROR.
4.. Call closesocket.
Note The shutdown function does not block regardless of the SO_LINGER
setting on the socket."

Our web server has SO_LINGER enabled on the socket, which means this
(according to the MSDN doc):

"If SO_LINGER is set with a nonzero time-out interval on a blocking socket,
the closesocket call blocks on a blocking socket until the remaining data
has been sent or until the time-out expires. This is called a graceful
disconnect. If the time-out expires before all data has been sent, the
Windows Sockets implementation terminates the connection before closesocket
returns."

In other words, the above is what IE should be doing to support "graceful
disconnects." Instead, what I was seeing is that when the web server is
finished sending the response of X size and then closing the socket, IE was
seeing a socket reset, thus reissuing the request per RFC HTTP
specifications. However, in my view, I don't think it is doing step 3
correctly.

By delaying the close on the web server, thus giving the send queue a chance
to finish the sending the data that IE is receiving, seems to have fixed the
problem. But as I said, in my technical view, this is not an ideal
solution. It helps solves the problem for us, for our customers using our
web server with their IE users, but in general, as I am sure you have
witness in recent days, IE will continue to have user reports of "Page
Cannot Not be Displayed" errors. In my view, it is a general problem in
IE for all web servers.

--
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
 
Hi Hector - Well, just tried the new test, and again I can't repeat the
error with any of several different size loads (but then I couldn't before
either). I also tried some local things just to eliminate them - I tried
adding the site to my HOSTS file, disabling the HOSTS file altogether, and
disabling BindPE TreeWalk (my normal local DNS server) to see if DNS
activities had any effect. None of these tests appeared to induce the error
either. Based on your success with the added delay, your analysis seems
reasonable, but I'm bothered that I couldn't reproduce it on the original
test, and I would like to verify that the failing instances of IE6 are fully
uptodate with fixes. Also, have you filed a "bug" report with MS on this,
including your analysis/fix?

--
Please respond in the same thread.
Regards, Jim Byrd, MS-MVP



In
 
Jim,

After all my analysis, I believe I finally solve the "IE puzzle." I had to
read up and get a better understanding of TCP/IP specifications. I am
posting this here to help others (users and developers) who run into similar
issues.

In my previous message, I indicated adding a sleep (thus delaying the
close), helped solve the problem we were experiencing with IE. I was not
comfortable with this sleep solution and continued with more investigation.

Again the MSDN documented indicated specific steps for a graceful shutdown
to send the remaining data. I took this mean it applied to a "receiver
application" (like a browser) since it is the server that is doing the send,
not receiving in this particular state. In addition, with the SO_LINGER
setting, the purpose of this option is to block a close while there is data
in the send queue. So I didn't these steps applied to the server attempting
to close the socket.

After analysis tcp/ip packets and read tcp/ip information in book TCP/IP
Illustrated Volume 1, specifically about "TCP Half Close" operations, I
realized the server using the recv() during a shutdown(), was not to expect
data, but instead expect the "half close" from the receiver.

So instead of using a sleep like so:

Send HTTP response
...
...

Sleep(300);
closesocket(sock)

I changed the logic to follow what the MSDN documentation says to do:

Send HTTP response
...
...

// notify receiver we are about to close, no more data will be sent.
// note: this does not close the socket

shutdown(sock,SD_SEND);

// new - wait until receiver closes socket.
// note: sanity check removed from loop

char buf[8*1024];
while (recv(sock, buf,sizeof(buf)) > 0);

// finally close the socket

closesocket(sock)

This fixed the problem! 100% with no sleeps and/or no send speed throttles.

This is the proper way to do it. I understand the TCP/IP specification
better now.

1) The shutdown() tells the receiver the server is done sending data. No
more data is going to be send. More importantly, it doesn't close the
socket. At the socket layer, this sends a TCP/IP FIN packet to the
receiver.

So when you send data, PSH (push data) packets are sent. The receiver
sends ACK packet for each PSH.

PSH 1 -->
<-- ACK 1
PSH 2 -->
<-- ACK 2
PSH 3 -->
<-- ACK 3
PSH 4 -->
<-- ACK 4

etc.. There is NO specific order to this. It can be:

PSH 1 -->
PSH 2 -->
<-- ACK 1
PSH 3 -->
<-- ACK 2
PSH 4 -->
<-- ACK 3
<-- ACK 4


And this depends much on the network transmission. i.e., ADSL connections
has a faster receive (download), slower send (upload).

When the shutdown() command is called, it will send a FIN signal. The FIN
can be in its own packet or part of the last PSH packet.

2) At this point, the socket layer has to wait until the receiver has
acknowledged the FIN packet by receiving a ACK packet. This is done by
using the recv() command in a loop until 0 or less value is returned. Once
recv() returns 0 (or less), 1/2 of the socket is closed.

3) Then you can close the second half of the socket by calling
closesocket();

According to TCP/IP Illustrated Volume 1, using Shutdown is not common in
applications (page 238, chapter 18.5): Most applications will terminate
the socket in both directions using the closesocket() command.

Summary:

If hosting applications do not support TCP Half Close, they might begin to
see problems with specific versions of Microsoft IE and/or combos of the
operating system.

Supporting TCP Half Close fixes and enhances our web server and solves this
problem for our customers who have IE users. So from our standpoint, the
problem is now solved.

Since our web server has been in existence since 1996 and has been well
engineered and put through the test of time, the recent avalanche of IE
issues tells me that Microsoft has changed something recently in either in
IE or in the Winsock layer in regards to SO_LINGER and closesocket(). The
net effect is that many users are now experiencing this "Page Cannot be
Displayed" and probably, without verification, for web sites not using the
Microsoft IIS web server. We are going to do a final test on this
presumption.

According to MSDN, using SO_LINGER is suppose to block the closing of the
socket until data in the SEND queue has been exhausted (sent). That's the
purpose of the SO_LINGER option and had always worked for us since we never
saw this IE issue before.

In other words, if there is still data in the send queue when the
closesocket() is called, the SO_LINGER socket setting (see setsockopt() in
MSDN) is suppose to BLOCK the sending the FIN packet to the receiver until
all the data has been sent.

However, this now brings up network transmission and packet sequence issues.

Although the socket send queue is now empty, depending on the user's
connectivity reliable and speed, it is my suspicion not all the PSH (push
data) packets were acknowledged by the receiver by the time it received a
FIN packet. Hence when a PSH packet arrived after a FIN, it was for a
closed socket. Hence according to RFC 793, if an out of sequence packet
arrives, a RST (reset) is sent back to the server.

This explains why we were seeing multiple resends of the URL request by the
IE browser.

For some people, they got the PAGE CANNOT BE DISPLAYED error. I
personally never saw this. Only the resends. I should note one of our
testers indicated this might depend on the IE setting "Show Friendly URL
errors" options. When ON, he got the page error. When Off, he got the
resends.

However, I am not sure that is consistent. It believe it all depends on the
network transmission, i.e, a timing issue related to the user's internet
connectivity.

In any case, the problem is solved for us.

I hope the above info provides some info to Microsoft and other host
developers who might run into the problem.

Thanks to All who tested this IE issue at our web site.
 
Jim, based on all the testers who didn't see the problem, including myself
when the report was first made and we did localize testing, I can
summarize that the problem does not show up when the transmission is "slowed
down" and/or TCP/IP packets are not out of sequence. This included:

1) Fast internet connectivity in both directions.

2) For some testers, they said the problem goes away of you have a proxy or
firewall or a packet sniffer.

I did not see the problem when I had ran the test against a local machine
web server or over our local network. However, when I finally took the
work home where I have a ADSL (near T1 download, 25% T1 uploads), I was
finally able to see the problem, albeit not the "page" error, instead the
page resets where after clicking SUBMIT with X number of lines, the browser
displayed the response but immediately resent the POST and finally a GET
request. Other testers got one or the other.

In my logs of the testing from over 50+ unknown people, I saw that many
also experienced the POST, POST, GET sequence. This is what piss me off
because they didn't have the courtesy to acknowledge either way what they
saw when I can clearly see in the logs they experienced it. I attributed
this either Microsoft or MVP people not wanting to make it public knowledge.
I even add an email address so that they can keep it private if that was the
case.

Anyway, this is typical example what I saw in the logs that show unknown
people also saw the problem. I removed the IP addresses to protect the
innocent. <g>

Initial connection, he clicked on my URL on the news article:

02:51 GET fid: 15989 id: 15989 lines: 0 in: 0 out: 0

The form indicates 143 lines is where the problem seems to begin, so he
enters 142. A experience tester who knows how to create a base line.

02:51 POST fid: 15989 id: 15992 lines: 142 in: 0 out: 7276

In: means noting in the text box when the post was submitted, out means the
amount of bytes created for the text box for 142 lines.

He now clicks again:

02:52 POST fid: 15989 id: 15993 lines: 142 in: 7276 out: 7276

The in and out are the same as expected. He now increase the amount to
143:

02:52 POST fid: 15989 id: 15994 lines: 143 in: 7276 out: 7328

And now more data is send out. Now he clicks again......

02:52 POST fid: 15989 id: 15995 lines: 143 in: 7328 out: 7328
02:52 POST fid: 15989 id: 15996 lines: 143 in: 7328 out: 7328
02:52 GET fid: 15997 id: 15997 lines: 0 in: 0 out: 0

and he gets the initial POST, followed immediate by IE sending a POST and a
GET again. I can tell by the fid: which is the session id. It is the same
for all the request except the last one.

He realized he sees the problem and says,

"hmmmmmm, maybe this hector guy isn't crazy! I though I had a
perfect system.
What's going on? Let me checks a few things...."

So he comes back again at 03:34 and repeats the process, again starting with
a base line at 100 and then going to 143 lines.

03:24 GET fid: 16077 id: 16077 lines: 0 in: 0 out: 0
03:25 POST fid: 16077 id: 16079 lines: 100 in: 0 out: 5092
03:25 POST fid: 16077 id: 16080 lines: 100 in: 5092 out: 5092
03:25 POST fid: 16077 id: 16081 lines: 143 in: 5092 out: 7328
03:25 POST fid: 16077 id: 16082 lines: 143 in: 7328 out: 7328
03:25 POST fid: 16077 id: 16083 lines: 143 in: 7328 out: 7328
03:25 GET fid: 16084 id: 16084 lines: 0 in: 0 out: 0

Get got the same result. He goes away again to further check on some
things, like IE settings or something and come back at 03:30am again and
sees it again, goes away again and comes again 9 minutes later, etc. This
goes on a few more times and says "shit, I'm going to bed!"

Same pattern with many others who tried it.

They just didn't say anything to me :-)

Anyway, as I posted in my last message discussing the solution, I am pretty
confident of the problem and solution, and how it all relates to TCP Half
Close and network transmission timing issues.

I don't believe it is coincidence and I am fairly confident this is
explaining the recent avalanche of IE user reporting "page cannot be
displayed" issues reported all over the net.

As to why? I am not sure. It is because Microsoft has made recent changes
to the socket layer and/or IE in how it receives large buffers to address
buffer overflow issues? It is coincidence that after the most recent
security vulnerability flaw fixes, including ComboBox, ListBox, ActiveX
buffer overflow issues, that IE users are not seeing this error in massive
groves?

Or could this be a matter of Microsoft internally wanting to "break" non-IIS
web servers? To make older web servers "obsolete", for forcing vendors to
make changes or risk IE compatibility issues? "Hey, IE works fine on IIS
servers! Switch!"

Who knows? :-)

--
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
 
Hi Hector - It looks like you've given the same URL for both. ?

--
Please respond in the same thread.
Regards, Jim Byrd, MS-MVP



In
 
No, try it. This is not IIS <g>

One goes to the host machine wctest.santronics.com and the other goes to
host machine www.winserver.com, two different machines.

The resource (/public/code/html-ietest5) is requested by the web host from
the Wildcat! server (another machine), and loaded on the web host machine so
that it can be run. Basically when you connect to the web server and send
the request, the web server will ask our centralize Wildcat! Internactive
Net server (WINSERVER) for everything. Nothing is local except for
temporary files.

/public is an alias that says authetication is not required.
/code is an alias for a script compiled image.

Take /public out and it will ask you to authenticate. (You can use the
guest/quest account)

In others words, all web server related resources are centralized in another
location. The web server are RPC clients to the Wildcat! RPC server where
everything is kept.

Hopes that helps
 
OK, Hector - Sorry, I just misread it. Alright, I retried the original test
recreating my DNS variants as I previously described. I am completely
unable to recreate the problem. DebugView shows no errors reported, as
well. I asked before if you could provide any data as to the OS/SP and IE
patch levels of the failing IE6s so that I can see if there's any apparent
pattern related to a patch problem which could then be checked by possibly
uninstalling the suspect patch. This is one possiblility, since I believe
that at least one of the more recent security patches does affect part of
the stack, though this would take more investigation. Another is that there
are several known cases of malware which affect Winsock, although usually as
a result of removal of the malware and usually by preventing connection.

--
Please respond in the same thread.
Regards, Jim Byrd, MS-MVP



In
 
Ok, so you were one of the few that it worked for. Here is your log:

22:43 GET fid: 27828 id: 27828 ntext: 0 in: 0 out: 0 wctest.santronics.com
22:43 POST fid: 27828 id: 27830 ntext: 200 in: 0 out: 10292
wctest.santronics.com
22:44 POST fid: 27828 id: 27831 ntext: 200 in: 10292 out: 10292
wctest.santronics.com
22:44 POST fid: 27828 id: 27832 ntext: 200 in: 10292 out: 10292
wctest.santronics.com
22:44 POST fid: 27828 id: 27833 ntext: 200 in: 10292 out: 10292
wctest.santronics.com
22:44 POST fid: 27828 id: 27834 ntext: 450 in: 10292 out: 23292
wctest.santronics.com
22:44 POST fid: 27828 id: 27835 ntext: 450 in: 23292 out: 23292
wctest.santronics.com
22:46 POST fid: 27828 id: 27841 ntext: 450 in: 23292 out: 23292
wctest.santronics.com
22:46 POST fid: 27828 id: 27842 ntext: 450 in: 23292 out: 23292
wctest.santronics.com
22:46 POST fid: 27828 id: 27843 ntext: 450 in: 23292 out: 23292
wctest.santronics.com
22:46 POST fid: 27828 id: 27844 ntext: 450 in: 23292 out: 23292
wctest.santronics.com
22:46 POST fid: 27828 id: 27845 ntext: 145 in: 23292 out: 7432
wctest.santronics.com
22:46 POST fid: 27828 id: 27847 ntext: 145 in: 7432 out: 7432
wctest.santronics.com
22:47 POST fid: 27828 id: 27848 ntext: 150 in: 7432 out: 7692
wctest.santronics.com
22:47 POST fid: 27828 id: 27849 ntext: 150 in: 7692 out: 7692
wctest.santronics.com
22:47 POST fid: 27828 id: 27850 ntext: 150 in: 7692 out: 7692
wctest.santronics.com
22:47 POST fid: 27828 id: 27851 ntext: 150 in: 7692 out: 7692
wctest.santronics.com
22:48 POST fid: 27828 id: 27855 ntext: 150 in: 7692 out: 7692
wctest.santronics.com

Your session id was retained.

Like I said, I don't know for sure what everyone's version were. I
personally have IE 6.0 on Win2K that exhibited the problem.

Thanks for your time. Its fixed now for our server.
 
Back
Top