HTTPClient FAQ

General

All goes fine, until I try to do a request to a site that requires authorization. The authorization popup either doesn't appear, or it appears but then everything hangs.

What you are probably doing is making the request from inside an AWT event handler. Don't! The problem is that while you're in an event handler no other events can get processed, including any event for the popup. There are two solutions to this:

1. Don't do any request from inside an event handler. This can be achieved by either starting a new thread which does the request, or by setting a flag and having the main thread do it (this is the way it's done in the Example Applet).
2. Install your own Authorization Handler which doesn't use the AWT (see AuthorizationInfo.setAuthHandler). However, I recommend the previous solution, as in general it is bad practice to do any sort of extended work inside an event handler (i.e. the code in the handler should execute quickly and return so that other events can be handled).

Applet specific

I keep getting the message "#Security Exception: properties" in the Java Console everytime my Applet starts.

This can be ignored. What is happening is that the static initializer of the HTTPConnection class tries to read a couple properties and this results in a SecurityException (in an Applet). This exception is caught inside the initializer, but Netscape's AppletSecurityManager prints the above message before throwing the exception. The properties that are being tried are "proxySet" and "socksHost", which can be set by applications to enable proxies.

I keep getting the message "#Security Exception: thread" in the Java Console.

This one is a little trickier. I assume the HTTPClient is being called from an AWT event handler? Then what is happening is the following. To keep a connection from staying open indefinitely when using persistent connections, the HTTPClient uses a timeout thread to close the connection if it's been idle for more than 10 seconds. To prevent applications from hanging at exit this thread is made a daemon thread when created (using setDaemon(true)). Furthermore, the thread is created when sending a request, and is therefore created in the context of whatever thread is calling HTTPClient. The problem now is that the AWT event handler runs in thread of its own which belongs to the main thread group java.lang.ThreadGroup, but applets are only allowed to manipulate threads in the AppletThreadGroup (this includes stop()'ing a thread or doing a setDaemon()). Now if the HTTPClient is called from an event handler the timeout thread is created belonging to the main thread group, and any attempt at modifying it will therefore result in a security exception.

This message can actually be ignored too, as it doesn't matter whether the thread is a daemon or not in applets and the security exception is caught internally. However, it's not good practice to call HTTPClient from an event handler, as potentially long running stuff should be done in the main thread or a thread of its own (otherwise you lock up the event handling during that time). For an example of how to let the main thread do things see the simple Example Applet.

Application specific

My application reaches the end, and then instead of exiting just hangs.

What is probably happening is that there are some (non daemon) threads still around that haven't exited. An application won't exit until all (non deamon) threads are dead. Here is one reason why a thread might still be around (apart from any you might have started and not stopped yourself):

1. The AWT uses a number of (non daemon) threads which are never killed. If the authorization popup appeared then these AWT threads were started and will therefore still be around at program exit time. In this case you need an explicit "System.exit(0)" at the end of your program.