A growing number of people are trying to misuse HTTP to create a full-duplex connection between the client and server. However, you can't, really. I will try to explain here why, and under what circumstances you could almost do so anyway.
The first thing to note is that HTTP uses a request-response paradigm, not a full-duplex streaming paradigm. Let me repeat that: HTTP is a request-response protocol! This means that the client sends a request, and when the complete request has been sent then the server sends the response. This is the case even if so-called keep-alive is used, i.e. multiple requests are sent over the same TCP connection. Because this behaviour is fundamental to the protocol most implementations make certain (valid) assumptions which make it (usually) impossible to create a full-duplex connection.
If you are wanting to create a full-duplex connection through HTTP anyway then you must ask yourself why. Why not just use TCP? After all, that's exactly what TCP gives you. The reasons I usually hear are that 1) you don't want to write a standalone server, but instead want to use the web server that's already running; or 2) the application needs to work through a firewall, and the only way to get through it is by using HTTP. Unfortunately, the work involved to get it working will probably negate any advantages 1) might seem to offer.
Ok, down to the details. We'll first discuss the problems when no proxy is involved, and then discuss the added problems a proxy generates.
The problems here are the following.
In summary, you may be able to get your server to provide you with a full-duplex connection, but chances are it would be easier to write your own (non-HTTP) server. Furthermore, using your own server is probably more efficient as HTTP servers are not designed for long requests and responses (you usually tie up a process or thread per connection).
When proxies are involved the above mentioned problems are compounded - now both the proxy (or proxies) and the server must fulfill the necessary requirements. I've especially seen the second point above as the major problem when going through a proxy: the proxy will wait until it has the complete request before forwarding it to the server. Additionally, while you may have control over the server (to the point of being able to write your own), you (generally) don't have any control over the proxy. This means you must assume the worst case for the proxy.
Furthermore, if you are writing an applet and don't sign it then you must use the browser's http client (via java.net.URLConnection - see Applet Network Security Policy for why). Unfortunately, these clients all first buffer the complete request data (i.e. everything written to the stream from URLConnection.getOutputStream()) before even sending the request, thereby preventing you from creating a true client->server stream.
As mentioned, the easiest solution is to either use TCP (i.e. java.net.Socket) directly, or to change your application to use a request-response paradigm. If you are trying to tunnel through an HTTP proxy and for some reason really can't change your paradigm, then here are a couple ideas.
In either case you will still have either write your own (simple) HTTP server, or then write some server side handler using an API native to the server.