This response may be a bit pedantic, but will hopefully clear up the issue.
Web Server 101 ... with vague generalities that will probably get me flamed.<g>
A web server, in its most elemental form, simply listens for and responds to HTTP requests. Basically that means it gets an HTTP request (a
string in a specified form), determines what resource (think HTML file) the request is for and sends the content of the resource (file) back to the requestor, formatted as an HTTP response. That is basically all a web server does. Other than the specific of parsing/assembling the HTTP requests/responses and locating resources, (involved and initially trivial, respectively) the code I posted earler, and that you have written, is the core of a web server.
So a web server is an application that understands HTTP protocol. Fine ... call 'em "HTTP servers", its more accurate, more precise and avoids HTML involvement that the server doesn't really care about.
In your case you have an HTML file that contains an applet tag. The HTML file is one resource, the applet is another. All the web server does is respond to requests for those resources (from a browser) and return the bytes that make up the page and the applet. Effectively this allows you to download code to the client. The client (the browser) then runs that code because it knows that it Java byte code (the response includes type information). In this example, the browser is far more sophisticated than the server.
All fine up to now, you have gotten code loaded on a client and it is running. Now the applet wants to communicate with a server. Assuming it is going to be through a socket, the first question is what protocol? That is, what is the client going to send to the server and what is the server going to respond with? Also, what is the messaging pattern? Will the client always initiate a request, followed by a server response? Can the server send an unsolicited message to the client?
==>Draw boxes for the client(s) and servers, connect them with lines and then determine what goes from the client to the server, to the other client, etc ... Then think about the perspective of each box (i.e. server waits for messages and responds, client sends message and waits for response, etc ...)
The applet is not restricted to HTTP or any other defined protocol, it can send whatever it wants down the wire. BUT, it is restricted to talking to only the server it was loaded from, that is a function of Java sandbox security (and maybe why you are getting the exception, see references below).
Once you answer all that stuff about messaging pattern and content then you can determine if HTTP is a valid choice for the protocol and if it is then you may be able to use a web server as your chat server. Read on ...
=> The short answer is that it will work but not particularly well, which implies that a web server is not the optimal solution. The bit about drawing boxes and the perspective of each box should illustrate why.
Now to slightly more complex stuff. In HTTP the requested resource does not have to be a static file. For example a request for an HTML page with the the current time must change constantly. That is where active server content in one form or another comes in, that may be servlet/JSP, PHP, Ruby, ASP, ASP.net, CGI, ISAPI DLL, etc. But basically the interface is the same, that is:
Request - the name of the resource and possibly some parameters
Result - the resource contents as a stream of bytes (with some type information)
Note that the fact that the protocol is HTTP has not changed. The browser knows nothing about how the content is generated, it just gets back a stream of bytes and either displays it or executes it (again depending on type, which is part of the response).
If active content on an HTTP server is the route you decide to take, then pick a technology and then pick a server that implements it.
==> Summary
You're doing this for the education, right? If not, find an existing IRC server/client implementation and install it.
An HTTP server is probably not the best fit.
The ability to download and run Java code can be addressed with WebStart without the limitations on server communication of an applet.
This problem has already been solved and codified (see below for IRC), implement to that spec, or at least read enough of it to understand the rationale.
Deploying a generic Java (server) application on a hosted system is gonna' be half a step from impossible. If you do have the intention of deploying this commercially, you may have to host it yourself.
Despite all that, it does sound like you are on the right track. The problem may be more complex than originally thought.
References:
HTTP protocol
ftp://ftp.isi.edu/in-notes/rfc2616.txt you don't have to read it from cover to cover, just the basics of request and response format
IRC (chat) protocol
http://www.irchelp.org/irchelp/rfc/ this problem has been solved, even if you don't implement the entire spec the basics of the messaging will be the same
Java tutorial on applets/server communication:
http://java.sun.com/docs/books/tutorial/deployment/applet/clientExample.html ... and maybe find your exception answer here.
Run TCP Monitor and watch HTTP browser/server interaction (you must download Axis to get it). This is most illuminating ...
http://ws.apache.org/axis/java/user-guide.html#AppendixUsingTheAxisTCPMonitorTcpmon