Often, certain errors such as missing images, non working JS files etc, pop up (i.e. customer calls and says “your Web app is totally broken”), and its very hard to determine whats happening. You could now add logging capabilities to your Web application and try to find out whats happening. That’s not a bad idea, but often it would help more to see what’s really sent over the wire, which resources fail to load etc.

Firefox: Firebug

For Firefox there is Firebug. Firebug is kind of a Swiss Army knife for all sorts of analyzing from within the Firefox Web browser. From JavaScript debugging, over JavaScript profiling, CSS and DOM explorer down to a network logger. For a nice introduction how to install and use Firebug see here.

The first thing you should always check with a faulty Web application is, if it loads all resources correctly. This can be done in the Network tab:

In this case the first two requests are answered by an HTTP 200 code, which means successfully loaded. The following request are all answered by HTTP 304, which means the resource has not been modified since the browser requested it last time. In other words these resources are cached.

Anytime there is an invalid request (wrong path, file does not extist), Firebug will mark that with an HTTP 404 response code, highlighted in red. This is very handy.

Internet Explorer: Fiddler

For IE there is Fiddler. Fiddler is a “debugging HTTP proxy”, which directly integrates with IE (but is not limited to). Once Fiddler is started from IE’s Tools menu, it willopen a port and automatically registers IE to use that as proxy location. (You can also register Firefox or any other browser to use that proxy) All subsequent requests will go through fiddler then, which generates well organized logs, like the following one:

This lets you drill down into the communication between your web browser and web server. For DOM or CSS inspection you would need an other tool though: Internet Developer Toolbar. And for JavaScript debugging you would need yet another tool: Visual Studio.

Running IntraWeb applications right off your desktop is simple and fast. Just compile and run, and you have a working HTTP server. For production we recommend installing as service or as ISAPI application though.

Running a Web server on a Windows desktop – where you need to be logged in – is not what you want typically.

However, for product demonstrations, long testing sessions etc. it might make sense to use an IntraWeb Standlone application that way. You could even run an IntraWeb application right off a CD. For that purpose
we offer a way to customize the more or less ugly default Standalone form. This can be done by just dropping a TIWStandaloneServer component onto a standard Windows VCL form. For more details see the
CustomStandAlone demo, which can be found in the “demos” folder where you installed IntraWeb.

We just got a customer inquiry, where a customized IntraWeb standalone application raises an Integer overflow after “lots of traffic”. The customer is implementing an online game with many graphics transfered.

The source of that problem is a LogBytes rountine which counts the transfered data using an Integer variable. In other words, after 2GB of data transfered the application will show an error.

Note: This error only applies to Desktop Standalone Applications.
ISAPI and Service type Standalone applications are not affected!

The next minor IntraWeb release (9.0.40) correctly handles that situation, and the next major release (9.1 or 10.0) will upgrade the variable in question to In64.

If you are using IntraWeb desktop applications in the described way, then add the following to your custom Standalone form:

private
  FTotalBytes := Int64;
  ...

procedure TFormCustom.LogBytes(const ABytes: Integer);
begin
FTotalBytes := FTotalBytes + ABytes;
//If you want to display the bytes transfered, then call your update routine here
//Or more resource friendly add a TTimer that updates your Byte counter
end;

procedure TFormCustom.FormCreate(Sender: TObject);
begin
memoLog.Lines.Add('Server started');
memoLog.Lines.Add('Listening on port: ' + IntToStr(GServerController.Port));
memoLog.Lines.Add('');
GLogBytesProcedure := LogBytes;
end;