The restriction is in place because "content" may be a stream that creates data on the fly and is not repeatable. In particular, neither client nor server will send the message body twice. If you want to modify content, you can either wrap a stream that modifies on the fly, or you can use a BufferedEntity that will keep the content in memory all at once. The latter will cause problems if content is large. hope that helps, Roland
I still have a bit of confusion so a little more "basic" information might clear my head. I guess when I look at it I see that I have a response object and inside is the entity (content). To me it looks as if the entire data should already be in the reposne (I see this is not the case but it is how I was thinking last night). So what you are saying is that the response will have headers but the actual content "may" reside on the other end of an InputStream ? Meaning that the content (probably dynamic) will not be rendered by the remote application until I physically read the data from InputStream ? Is this the case? I guess I assumed if you have response headers then you would have the content as I thought it comes all at once from the remote web server. Could you simply explain this process or point me to something that might explain it clearly? thanks again! Doug ---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- What profits a man if he gains the whole world yet loses his soul?
