|
Home > Archive > IIS Server > August 2004 > two iis 6 servers same asp code buffering differently
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
two iis 6 servers same asp code buffering differently
|
|
|
| Hi All,
This may be an old question, but there's little useful references online
that I've been able to find.
I want the following code to display bit by bit, not send all at once to the
client (IE).
The following code sample works as intended on all NT4 Wkstation PWS and on
*one* IIS6 W2K3 server. On all other W2K3 servers it does not, it waits and
sends the whole page at once.
BTW same effect if bufferring is true OR false!
What might cause the difference between 2 IIS 6 servers in this case? I'm
looking to IIS config rather than code ... but i'm open to suggestions there
too!
With Thanks,
BS
---- CODE SAMPLE ---
<% Response.Buffer = true %>
<%
Sub delay(n)
Dim endTime
endTime = dateadd("s", n, Now())
do while Now() < endTime
loop
End Sub
%>
<html>
<head>
<script language="javascript">
document.writeln ("js:header test<BR>");
</script>
</head>
<body>
<%
Response.Flush
Dim i
Response.Write "<HR>" & Now() & "<HR>" & vbCrLf
for i = 1 to 5
Response.Write "<script language=""javascript"">" & vbCrLf
Response.Write "document.writeln (""js:test " & CStr(i) & "<BR>"");" &
vbCrLf
Response.Write "</script>" & vbCrLf
delay (2)
Response.Flush
next
Response.Write "<HR>" & Now() & " All Done.<HR>"
%>
</body>
</html>
<% Response.Flush %>
---- CODE END ----
| |
| David Wang [Msft] 2004-08-24, 7:06 pm |
| You must first fix your web page. Your webpage is rendering a broken
response that depends on web browser behavior. If you want consistent
behavior, you must have a non-broken web page. Until you show a network
trace that illustrates response packets being "buffered" by IIS before
sending it (vs the client buffering the unknown length response before
displaying it), there is no proof that IIS6 is actually buffering.
Response.buffer = true tells ASP to buffer the response to be sent at
once, using Content-Length to indicate to client the length of the response.
Response.buffer = false tells ASP to send the response immediately as-is,
using Transfer-Encoding: chunked to indicate to the client when the response
ends (with a 0-length chunk).
Your current web page, with Response.Buffer = true and using Response.Flush,
does not send a Content-Length nor Transfer-Encoding: chunked, so behavior
completely depends on the client that renders the response. A response
without the Content-Length and Transfer-Encoding headers is basically broken
because even though the server is dribbling data, the client has no way to
know how long the response actually should be -- so behavior is
client-dependent.
If you set Response.Buffer = false and remove all the Response.Flush calls,
then Transfer-Encoding: chunked will be sent, and the client will get the
same dribble of response every 2 seconds -- but the client knows that a
0-byte chunk signals the end of the response and may choose to render the
response on-the-fly instead of waiting.
On my default installed W2K3 machine, I see the test string slowly progress
down the web page for both web pages. But just because a page renders does
not mean it is correct.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"BS" <BS@discussions.microsoft.com> wrote in message
news:AD03FE15-958B-483F-9529-9E9F21720746@microsoft.com...
Hi All,
This may be an old question, but there's little useful references online
that I've been able to find.
I want the following code to display bit by bit, not send all at once to the
client (IE).
The following code sample works as intended on all NT4 Wkstation PWS and on
*one* IIS6 W2K3 server. On all other W2K3 servers it does not, it waits and
sends the whole page at once.
BTW same effect if bufferring is true OR false!
What might cause the difference between 2 IIS 6 servers in this case? I'm
looking to IIS config rather than code ... but i'm open to suggestions there
too!
With Thanks,
BS
---- CODE SAMPLE ---
<% Response.Buffer = true %>
<%
Sub delay(n)
Dim endTime
endTime = dateadd("s", n, Now())
do while Now() < endTime
loop
End Sub
%>
<html>
<head>
<script language="javascript">
document.writeln ("js:header test<BR>");
</script>
</head>
<body>
<%
Response.Flush
Dim i
Response.Write "<HR>" & Now() & "<HR>" & vbCrLf
for i = 1 to 5
Response.Write "<script language=""javascript"">" & vbCrLf
Response.Write "document.writeln (""js:test " & CStr(i) & "<BR>"");" &
vbCrLf
Response.Write "</script>" & vbCrLf
delay (2)
Response.Flush
next
Response.Write "<HR>" & Now() & " All Done.<HR>"
%>
</body>
</html>
<% Response.Flush %>
---- CODE END ----
| |
|
| Hi David,
Thanks for the response. I'm using the same page tested using the same
browser each time it cannot be browser dependent in this case - can it? I
have also tested from other browsers (all IE 6) onsite all are consistent.
Its dependent on the server not the client.
I've tried the page with response.buffer=false too (new example below).
So for *the same page, on 2 different IIS 6 W2K3 servers* testing from *the
same client browser* I see response from one server appear to be dribbled out
but from the other server the browser does not disply the page until its all
ready.
Once again the desired result is to see the page progressivley render using
the same browser across both - and ultimately all servers.
With Thanks,
Banos.
---- NEW CODE START ----
<% Response.Buffer = false %>
<%
Sub delay(n)
Dim endTime
endTime = dateadd("s", n, Now())
do while Now() < endTime
loop
End Sub
%>
<html>
<head>
<script language="javascript">
document.writeln ("js:header test<BR>");
</script>
</head>
<body>
<%
Dim i
Response.Write "<HR>" & Now() & "<HR>" & vbCrLf
for i = 1 to 5
Response.Write "<script language=""javascript"">" & vbCrLf
Response.Write " document.writeln (""js:test " & CStr(i) & "<BR>"");" &
vbCrLf
Response.Write "</script>" & vbCrLf
delay (2)
next
Response.Write "<HR>" & Now() & " All Done.<HR>"
%>
</body>
</html>
--- CODE END ----
"David Wang [Msft]" wrote:
> You must first fix your web page. Your webpage is rendering a broken
> response that depends on web browser behavior. If you want consistent
> behavior, you must have a non-broken web page. Until you show a network
> trace that illustrates response packets being "buffered" by IIS before
> sending it (vs the client buffering the unknown length response before
> displaying it), there is no proof that IIS6 is actually buffering.
>
> Response.buffer = true tells ASP to buffer the response to be sent at
> once, using Content-Length to indicate to client the length of the response.
>
> Response.buffer = false tells ASP to send the response immediately as-is,
> using Transfer-Encoding: chunked to indicate to the client when the response
> ends (with a 0-length chunk).
>
>
> Your current web page, with Response.Buffer = true and using Response.Flush,
> does not send a Content-Length nor Transfer-Encoding: chunked, so behavior
> completely depends on the client that renders the response. A response
> without the Content-Length and Transfer-Encoding headers is basically broken
> because even though the server is dribbling data, the client has no way to
> know how long the response actually should be -- so behavior is
> client-dependent.
>
> If you set Response.Buffer = false and remove all the Response.Flush calls,
> then Transfer-Encoding: chunked will be sent, and the client will get the
> same dribble of response every 2 seconds -- but the client knows that a
> 0-byte chunk signals the end of the response and may choose to render the
> response on-the-fly instead of waiting.
>
> On my default installed W2K3 machine, I see the test string slowly progress
> down the web page for both web pages. But just because a page renders does
> not mean it is correct.
>
| |
| David Wang [Msft] 2004-08-27, 6:18 pm |
| You should capture a Network trace of the response being dribbled from one
server and sent-at-once from the other, both from the server and client, of
the exact same request.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"BS" <BS@discussions.microsoft.com> wrote in message
news:9EBD81EE-7AC5-477F-90BA-8DD912B2C92A@microsoft.com...
Hi David,
Thanks for the response. I'm using the same page tested using the same
browser each time it cannot be browser dependent in this case - can it? I
have also tested from other browsers (all IE 6) onsite all are consistent.
Its dependent on the server not the client.
I've tried the page with response.buffer=false too (new example below).
So for *the same page, on 2 different IIS 6 W2K3 servers* testing from *the
same client browser* I see response from one server appear to be dribbled
out
but from the other server the browser does not disply the page until its all
ready.
Once again the desired result is to see the page progressivley render using
the same browser across both - and ultimately all servers.
With Thanks,
Banos.
---- NEW CODE START ----
<% Response.Buffer = false %>
<%
Sub delay(n)
Dim endTime
endTime = dateadd("s", n, Now())
do while Now() < endTime
loop
End Sub
%>
<html>
<head>
<script language="javascript">
document.writeln ("js:header test<BR>");
</script>
</head>
<body>
<%
Dim i
Response.Write "<HR>" & Now() & "<HR>" & vbCrLf
for i = 1 to 5
Response.Write "<script language=""javascript"">" & vbCrLf
Response.Write " document.writeln (""js:test " & CStr(i) & "<BR>"");" &
vbCrLf
Response.Write "</script>" & vbCrLf
delay (2)
next
Response.Write "<HR>" & Now() & " All Done.<HR>"
%>
</body>
</html>
--- CODE END ----
"David Wang [Msft]" wrote:
> You must first fix your web page. Your webpage is rendering a broken
> response that depends on web browser behavior. If you want consistent
> behavior, you must have a non-broken web page. Until you show a network
> trace that illustrates response packets being "buffered" by IIS before
> sending it (vs the client buffering the unknown length response before
> displaying it), there is no proof that IIS6 is actually buffering.
>
> Response.buffer = true tells ASP to buffer the response to be sent at
> once, using Content-Length to indicate to client the length of the
response.
>
> Response.buffer = false tells ASP to send the response immediately as-is,
> using Transfer-Encoding: chunked to indicate to the client when the
response
> ends (with a 0-length chunk).
>
>
> Your current web page, with Response.Buffer = true and using
Response.Flush,
> does not send a Content-Length nor Transfer-Encoding: chunked, so behavior
> completely depends on the client that renders the response. A response
> without the Content-Length and Transfer-Encoding headers is basically
broken
> because even though the server is dribbling data, the client has no way to
> know how long the response actually should be -- so behavior is
> client-dependent.
>
> If you set Response.Buffer = false and remove all the Response.Flush
calls,
> then Transfer-Encoding: chunked will be sent, and the client will get the
> same dribble of response every 2 seconds -- but the client knows that a
> 0-byte chunk signals the end of the response and may choose to render the
> response on-the-fly instead of waiting.
>
> On my default installed W2K3 machine, I see the test string slowly
progress
> down the web page for both web pages. But just because a page renders
does
> not mean it is correct.
>
| |
|
| To wrap this one up.
jetNexus on one server, not on the other. Thanks for the pointers. The
jetNexus header turned up on one server only.
Regards,
Banos.
"David Wang [Msft]" wrote:
> You should capture a Network trace of the response being dribbled from one
> server and sent-at-once from the other, both from the server and client, of
> the exact same request.
>
> --
> //David
> IIS
> This posting is provided "AS IS" with no warranties, and confers no rights.
> //
> "BS" <BS@discussions.microsoft.com> wrote in message
> news:9EBD81EE-7AC5-477F-90BA-8DD912B2C92A@microsoft.com...
> Hi David,
>
> Thanks for the response. I'm using the same page tested using the same
> browser each time it cannot be browser dependent in this case - can it? I
> have also tested from other browsers (all IE 6) onsite all are consistent.
> Its dependent on the server not the client.
>
> I've tried the page with response.buffer=false too (new example below).
>
> So for *the same page, on 2 different IIS 6 W2K3 servers* testing from *the
> same client browser* I see response from one server appear to be dribbled
> out
> but from the other server the browser does not disply the page until its all
> ready.
>
> Once again the desired result is to see the page progressivley render using
> the same browser across both - and ultimately all servers.
>
> With Thanks,
> Banos.
>
> ---- NEW CODE START ----
> <% Response.Buffer = false %>
>
> <%
> Sub delay(n)
> Dim endTime
>
> endTime = dateadd("s", n, Now())
> do while Now() < endTime
> loop
> End Sub
> %>
> <html>
> <head>
> <script language="javascript">
> document.writeln ("js:header test<BR>");
> </script>
> </head>
> <body>
> <%
>
> Dim i
>
> Response.Write "<HR>" & Now() & "<HR>" & vbCrLf
>
> for i = 1 to 5
> Response.Write "<script language=""javascript"">" & vbCrLf
> Response.Write " document.writeln (""js:test " & CStr(i) & "<BR>"");" &
> vbCrLf
> Response.Write "</script>" & vbCrLf
>
> delay (2)
> next
>
> Response.Write "<HR>" & Now() & " All Done.<HR>"
>
> %>
> </body>
> </html>
> --- CODE END ----
>
>
> "David Wang [Msft]" wrote:
>
> response.
> response
> Response.Flush,
> broken
> calls,
> progress
> does
>
>
>
|
|
|
|
|