|
Posted by Chris Shiflett on 09/02/05 21:58
Rasmus Lerdorf wrote:
> Why modify my test?
Because it has less delay. Thus, it's more difficult to tell if the
browser is requesting the new URL before or after receiving the entire
response. My script is essentially the same thing, but the script takes
30 seconds to execute. It makes the distinction very clear.
The addition of flush() forces the chunked response. You can remove that
if your server uses chunked transfer encoding without it.
> What did you see in log.txt from my version and on your screen?
You would see the output "Count0\nCount1\n..." in the log and the PHP
web site in the browser. I'm not sure how that's relevant. No browser is
going to render content from a 302 response, but that doesn't prove that
it won't wait for it.
For the browsers I've tested (including Internet Explorer now), the new
request (for http://www.php.net/) is not sent until after the previous
response is received in its entirety.
> There are buffering issues on both ends here, but my original test
> describes shows exactly how browsers will redirect long before the
> end of a request.
Your script, without modifications, exhibits the same behavior. It's a
bit more difficult to visualize, but I can verify it with timestamps.
The request for http://www.php.net/ is not sent until after the previous
response has been received in its entirety.
I'd be curious to know which browser you're using that behaves
differently. I'm not saying it's not possible, but it seems weird.
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
[Back to original message]
|