Looking at your code, it appears to be a django log. I'm not sure why you are reading logs with a webpage when you can always read them using the terminal. cat, grep, tailf and a few other commands would be your friends in this case.

As @Flambino mentioned, direct access to the log is a problem. If you are going to pursue this method, you should at least have the server side validate your access. You could use a login system, and if the user isn't logged in, you can simply throw a 403 (Forbidden) as the result of the AJAX. Otherwise, return the log contents.

Now back to the code. First off, you could wrap everything in a closure. That way, nothing is modifiable from the global scope. That prevents naming collisions and all that. At least your code is protected from other code that may reside in your page.

;(function(){

  // all your code here

}());

Next, you can use an AJAX library to abstract out your XHR code. That way, you don't have to deal with all the intricacies of XHR. A good minimum that I use, which is also forward-compatible, is using a Promise and fetch polyfill. Promise is needed for fetch to work. It's just under 20kb when minified. Rather big but keeps you sane.

fetch(url).then(function(response){
  // This is a required intermediate parsing step for fetch
  return response.text();
}).then(function(responseText){
  // Do what needs to be done with the log
}).catch(function(error){
  // Do what needs to be done during error
});

Another suggestion is to use a <textarea> instead of a <div> as your log output. That way, you don't have to deal with formatting, collapsing of tabs, escaping of characters. You can always set it to readonly to prevent editing, and modify scrollTop on update if ever you always want the bottom to be visible.

Sever logs can be huge and will have impact on your fetching operation. This happens especially if your team is using the logger extensively for easy debugging. I suggest you have some server-side logic to paginate your results and not just dump everything into the page.

I noticed your funny little characters for the title bar. While they are fun, not all computers might have those glyphs built in. On my rig, this character (😞) doesn't appear, just a box with a question mark (or just a box on others). You might want to consider being creative in the ascii range of characters and not totally rely on these non-ascii ones.

On a side note, it appears as though you're trying to achieve something similar to what Scalyr does - a web-based log monitoring and search.

Looking at your code, it appears to be a django log. I'm not sure why you are reading logs with a webpage when you can always read them using the terminal. cat, grep, tailf and a few other commands would be your friends in this case.

As @Flambino mentioned, direct access to the log is a problem. If you are going to pursue this method, you should at least have the server side validate your access. You could use a login system, and if the user isn't logged in, you can simply throw a 403 (Forbidden) as the result of the AJAX. Otherwise, return the log contents.

Now back to the code. First off, you could wrap everything in a closure. That way, nothing is modifiable from the global scope. That prevents naming collisions and all that. At least your code is protected from other code that may reside in your page.

;(function(){

  // all your code here

}());

Next, you can use an AJAX library to abstract out your XHR code. That way, you don't have to deal with all the intricacies of XHR. A good minimum that I use, which is also forward-compatible, is using a Promise and fetch polyfill. Promise is needed for fetch to work. It's just under 20kb when minified. Rather big but keeps you sane.

fetch(url).then(function(response){
  // This is a required intermediate parsing step for fetch
  return response.text();
}).then(function(responseText){
  // Do what needs to be done with the log
}).catch(function(error){
  // Do what needs to be done during error
});

Another suggestion is to use a <textarea> instead of a <div> as your log output. That way, you don't have to deal with formatting, collapsing of tabs, escaping of characters. You can always set it to readonly to prevent editing, and modify scrollTop on update if ever you always want the bottom to be visible.

Sever logs can be huge and will have impact on your fetching operation. This happens especially if your team is using the logger extensively for easy debugging. I suggest you have some server-side logic to paginate your results and not just dump everything into the page.

I noticed your funny little characters for the title bar. While they are fun, not all computers might have those glyphs built in. On my rig, this character (😞) doesn't appear, just a box with a question mark (or just a box on others). You might want to consider being creative in the ascii range of characters and not totally rely on these non-ascii ones. For example, this sequence -\|/- for a rotating bar.

On a side note, it appears as though you're trying to achieve something similar to what Scalyr does - a web-based log monitoring and search.