Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Can't stream <script> tags to IE (Comet) 1

Status
Not open for further replies.

colorplane

Programmer
Aug 9, 2007
44
US
I have written a Perl HTTP server that pushes chat events to connected clients via <script> commands. Although Firefox and Opera work fine with XMLHTTPRequest, I am aware that IE will not allow access to the responseText or the innerHTML of an iframe until the connection has closed.

However, I cannot get IE to run the <script> tags in realtime (I believe this is why Comet programming like this usually works), instead they are all processed in a group after the request is complete. I wrote a test server and client which simply alert()s three times at 2-second intervals. FF and Opera display the alerts at the proper time but IE waits til the end.

Additionally, if I run the AJAX component of the script directly in the browser, IE 7 waits until the connection closes to alert() but only the first time. If I refresh the page, the alerts are delivered at the proper time (actually receiving the proper data from the server, it's not a weird cache behavior). IE 6 does not display the alerts in realtime even after a refresh.

If anyone has a suspicion as to what the problem might be, I am absolutely open to suggestions or fixes. For anyone with Perl who would like to test the sample server that I set up to demonstrate this, it can be downloaded from this post in the Perl forum:

I will be very grateful for any assistance!
 
Hi

randynchronize said:
However, I cannot get IE to run the <script> tags in realtime [gray](...)[/gray], instead they are all processed in a group after the request is complete.
Huh ? I played with this idea long time ago and always worked. Ok, I did not wrote a server yet, the following is the communication between Explore and me through [tt]netcat[/tt] :
Code:
[blue]GET / HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0
.50727)
Host: localhost:80
Connection: Keep-Alive[/blue]

[green]HTTP/1.0 200 Ok
Content-type: text/html

<html>
<head>
<title>LOL</title>
</head>
<body>
<script>
document.writeln('LOL')
alert('LOL')
[highlight pink]</script>[/highlight]
</body>
</html>[/green]
[ul]
[li][blue]blue[/blue] - Explorer[/li]
[li][green]green[/green] - Feherke[/li]
[li][highlight pink]pink[/highlight] - the line at which the previous [tt]script[/tt] section is evaluated[/li]
[/ul]
Now I tried again in Explorer 6 and FireFox, but I am sure it works in all modern browser.

Are you sure the problem is not in your [tt]perl[/tt] code ? Could you post some code or communication ?

Feherke.
 
I provided a link to the entire client and server script in the original post. I, too am afraid that the problem is with the perl server, but I posted this in both the perl and Javascript sections in case anyone had experienced this problem in either.

Do you happen to know what might cause IE to not evaluate the script at the </script> tags?
 
Additionally, although I agree that this may be a problem with the server, I don't think that the plain comet tags ( in the example) would work in Firefox if it were.

I added in the <html>, <head>, <body> tags each printed on their own line by perl but it still isn't working in IE. If you have perl installed you should be able to run the script and connect to to see the problem.

Also, netcat gets the data streaming as it should, here is a sample output in case you notice any issues:

Code:
netcat localhost 9090
comet
HTTP/1.0 200 OK
Content-type: text/html

<html>
<head>
<title>TEST</title>
</head>
<body>
<script>alert('a ' + 0)</script>
<script>alert('b ' + 2)</script>
<script>alert('c ' + 1)</script>
 
Hi

randynchronize said:
I provided a link to the entire client and server script in the original post.
Sorry, but I am even more stupid on Fridays. I do not understand, that Comet is your problematic chat solution or is the original which inspired you ?

Because that one works for me similarly in Mozillas, Opera and Explorer.

And no, I can not connect to localhost:9090, because I have nothing open on my machines port 9090.
randynchronize said:
Do you happen to know what might cause IE to not evaluate the script at the </script> tags?
Theoretically could be even a security patch... They "solve" certain security flows by disabling features.

Feherke.
 
feherke said:
And no, I can not connect to localhost:9090, because I have nothing open on my machines port 9090.
You're really against checking out the code, aren't you? The perl script is an HTTP server that runs on 9090 (or whatever you feel like changing it to). It only serves up two things - either the interface which connects to the server again to get the comet commands and display them, or the comet commands themselves =)


This is the example that I have been referring to when thinking about how to implement the client side in IE:
It uses the new ActiveXObject('htmlfile') with an iframe inside to contact the server without triggering the loading bar. The example on this site works in IE, so I am not willing to be convinced that what I am trying to do (I believe it's the same thing) will not. The biggest difference is that this is running on mod_perl and Apache. That's not an option for this application which must support more connections than Apache can.

feherke said:
Theoretically could be even a security patch... They "solve" certain security flows by disabling features.
I'm also afraid that it might be a security issue, can anyone confirm that?
 
For anyone interested in this post, I discovered the solution to the problem. Before Internet Explorer will start streaming Javascript commands or any content, it must receive 256 bytes of data. This is as simple as [tt]print $sock ' ' x 256;[/tt]

What a ridiculous solution. I found this in the last sentence of the PHP manual entry for "flush".
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top