Firstly, you can't serialize a HttpServletRequest or HttpServletResponse using Java serialization. Objects that conform to these APIs typically include references to "stuff" in the servlet implementation stack that is inherently non-serializable.
Second, you can't "redirect" a request to another client. It doesn't make sense from the perspective of the HTTP protocol.
A redirect happens when a client sends a request to a server and the server response has a 3xx status code that says "try that request somewhere else". It is a redirection to a different server, not a different client.
Even ignoring the details of what redirection means. You can't send an HTTP request to something that is in the HTTP client role. It won't be expecting it (listening for it), and wouldn't know what to do with it. (And indeed it would be a violation of the HTTP protocol.)
Thirdly, an "ordinary socket client" can't talk to an HTTP service (implemented using Servlets, or anything else). The client has to implement at least a subset of HTTP protocol in order to make itself understood by the HTTP service. It is possible to implement that "by hand", but IMO that's a bad idea ... when there are high quality implementations you can use for free.
In short, what you seem to be trying to do is impossible / nonsensical. (If I understand your Question correctly ... which is debatable.)
If you explained what you were actually trying to do here, we might be able to suggest sensible alternative approaches.
I'm trying to connect two java client applications across server. The client will be able to communicate directly with other client.
Literally you can't do that using HTTP. But you could build an HTTP server/servlet that transfers messages from one client to another; e.g.
- Client A sends a PUT request containing a message for A to server.
- Server stores message and replies to client A.
- Client B sends a GET request asking "any messages?" to server.
- Server looks up messages and responds with the message from A.
But note that you can't do that with plain socket clients. The clients have to be HTTP clients.
If you were prepared to ditch the requirement that the server was an HTTP server / servlet, you could have "simple socket" clients open duplex connections to the server, and have the server pass "messages" between the clients. This entails implementing a custom "protocol" for messaging.
A third alternative is to use an existing RPC or object broker technology; e.g. RMI, CORBA, ICE, etcetera
