Jump to content


  • Content Count

  • Joined

  • Last visited


Community Reputation

0 Neutral

About HaLo2FrEeEk

  • Rank
    Prolific Member
  • Birthday 08/17/1989

Contact Methods

  • Website URL

Profile Information

  • Gender
  1. Yeah uhm...I'm gonna let his reply speak for me.
  2. Ok, so I found out that if I output more than 64kb to the browser, it'll get sent, so basically all I have to do is output 64kb+ every iteration of my loop. Since that's not feasible, and since I know it's not a browser issue, I've written my host's tech support and they're working with me on the problem. The reason I know it's not a browser thing is because it does the same thing in both Internet Explorer and Firefox. It does this whether I have output buffering on or off and whether I ob_flush() and flush() or not.
  3. I'll try it, but I don't see how it's gonna help, we're talking about text here, not images or anything. I will try though and edit. Edit: Didn't make any difference. So I've created my own php.ini, and I know it's being used because I changed the value of output_buffering from 4096 to Off and the change was reflected in a phpinfo() print. Is there anything else I should change? changing the output_buffering setting didn't help. I've got zlib.output_compression set to Off also.
  4. I tried it but all that's happening is the script loads completely, waiting through the entire loop, then at the end the progress bar counts up really quickly while it executes all the Javascript. It doesn't output the buffer contents between each loop. I've contacted Dreamhost and they said that I can create my own local installation of php specific to my account, and I can apply it to a single domain. My PHP's output_buffering value is set to 4096, so I think I need to send more than 4096 bytes each time for the buffer to actually be output. I'll do a test and see if it works.
  5. I understand what you're saying, but I disagree. I know it's not my browser because every tool that I've used to check whether it's requesting compressed content reports that it indeed is. I've also checked Firefox with the same results. I know it's not my ISP because of the same thing I said above, how would those pages know I was requesting compressed content if it was being blocked by my ISP? Also, I can view other pages using this method, such as this one here: http://www.johnboy.com/php-upload-progress-bar/ Works just fine in both IE (my main browser) and Firefox. A
  6. That still didn't work. I just had to wait 20 seconds and all 20 numbers were printed at once. This is weird, because I've seen it done! I read everywhere that having gzip enabled disrupts this, so I had my host turn off gzip for that domain. Here are 2 pages that report that gzip is indeed turned off: http://www.whatsmyip.org/http_compression/?url=aHR0cDovL2hhbG8zc2hvdHMuaW5mZWN0aW9uaXN0LmNvbQ== http://www.port80software.com/tools/compresscheck.asp?url=halo3shots.infectionist.com Both report that this particular subdomain is not being gzipped. I asked my hosting provider
  7. Ok, I know ths is possible, an example is here: http://www.johnboy.com/php-upload-progress-bar/ It uses the ob_flush() and flush() functions of PHP. From what I've read, these functions have no effect if mod_gzip is enabled in your apache server. I'm on a shared hosting plan with Dreamhost and they have mod_gzip enabled, but you can request to have it turned off for certain subdomains. I did so, but it seems that it didn't have an effect. Here is my code: <?php ob_start(); for ($i = 0; $i < 5; $i++) { echo $i . "<br>"; ob_end_flush(); ob_flush(); flush
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.