Servlet Response Problem

Question

Hello all,
My simple servlet takes in a URL as a parameter and the uses the httpUrlConnection method to retrieve that page. It then just writes the html to the browser in the hope that it would be displayed as if retrieved directly.
Although the source of a page retrieved in this way is identicle to the expected source, no images appear. I think (guess) this is because the address of a page retrieved in this way will not be the same as if retrieved normally. This, in turn, messes up the relative file paths. e.g www.mypage.com becomes something like http://localhost/httpProxyServer?URL=http%3A%2F%2Fwww.mypage.com (httpProxyServer is the name of the servlet).
To get to the point, idoes anyone know if there is a way i can set the address of the returned page to be as if retrieved directly? I have looked in to response headers with little luck although i am very new to servlets. Thanks for any tips or advice.
Christie

Answer 1

This question can be better answered if you point out the need to examine each response before actually sending it out to the browser. What exactly do you look for in the response ? Do you compress it / transform it / parse it ?
Having said that, you could use filters to meet any of your above needs.
1. The first obvious gain is that it is a standard, widely accepted and part of the j2ee specification. As you said, it provides modularity and resuability of code. Somebody who goes through your work would easily pick up the trail, comprehend concisely the effort and the ends you attempt to achieve. You would have implicit server support (more of this later)
2. You use a servlet that intercepts each request. It then uses a HttpURLConnection to get the response from each resource. As you can see straight away, this essentially makes it two requests per request - the original request goes to your general purpose servlet; then the general purpose Servlet(GPS hereafter) makes the url connection to the resource, its a brand new request. The original request may have lots of params coming in which have to be reconstructed by the GPS and included in the call to the resource which delivers the actual response back to the GPS. Hope you begin to see the pitfalls here (for example imagine the incoming stream is a byte stream resulting from a file upload)
**in short** the 'simple servlet' is going to get very very complex as your application grows.
3. All the above rerouting (even if you manage to achieve it successfully) will take its toll on the performance measured in terms of the response time.
4. In established MVC2 framework like Struts or JSF, the Servlet that intercepts every request is a Controller Servlet (which knows how to handle the request, which validations to perform, which beans to invoke and so on). Your GPS should in addition to examining responses, do all this stuff or else you would end up with multiple Controllers making your app quite unwieldy.
5. Using filters, you could side step all the above which in itself is a huge advantage (me thinks :)) besides providing a standard way to implement tasks similar to yours. I mentioned implicit server support, right ? Filters are supported by all standard j2ee web severs. You neednt write a single line of code to have your filter modify the response. All you have to write is the actual modification algorithm. However the path you choose, you would have to manually do all the dirty work of transferring the request to the actual resource (using HttpUrlConnection). You should receive each request params and convey that to the resource being accessed and so on. (see #2 above)
Hope all that helps.
cheers,
ram.