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/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
