I expect this is simply because the file is opened, and there is no end-of-file reached yet, so the webserver keeps looking for the rest of the input until end-of-file. I'm not sure if eof is signaled or not in this case, so this is all theory.
You may need to write your own "tail -f" replacement for your webserver, grabbing everything that's in the file currently from a beginning index (first time through this will be zero), to the last byte (*), and send it back with the index of the end. Then repeated requests from the browser can ask for the same log file with the new index, receive the new data (if any) and append it to the data in the browser.
(*) This byte issue could haunt you if you write any multi-byte characters to the log file. However, given your use of autoflush and %n, this is unlikely to be an issue. One workaround is to have your server-side process only read up to \n's, and not return the last line unless it includes the \n in it. Then you can be assured you're sending full lines back to the browser. If you're using ISO-88591 characters only, or at least a single-byte encoding and language, then this is moot. I just have to worry about Chinese, Japanese, etc., characters showing up in my logs, so I pay attention to this.