Oleg, I followed your examples and I am getting an odd situation. Here is what I have: I have a simple process (I used the skeleton of the ElementalHttpServer for that). It creates a ServiceHandler that handles incoming connections. In the doService method I grab the clients request and make a new request to the webserver using HttpRequestExecutor. I followed the code examples for ElementHttpGet for that. I add my ResponseFilterInterceptor to the httpexecutor and then execute it. When I check the response the content length header is set to 12609 ( the correct value) but when I try and open the input stream in the EntityWrapper (in the writeTo method) the available() call to the input stream returns 0. So I seem to have no data in the stream.
What could cause this? I checked and it seems that the inputstream has 0 bytes even right after the httpexecutor call. I have not played with the headers much and I am making a real simple request to the server for a static file so I do not see what the problem could be. Any help/pointers would be appreciated. thanks Doug On 8/29/06, Doug Lochart <[EMAIL PROTECTED]> wrote:
Thats funny. The first thing I did when I cracked open HttpCore was write an interceptor that dumped data out of the request and response objects just to see how things worked. For some reason I got caught up in some other idea of how things flowed and for some reason I did not think that an interceptor was the way to go. I will give it a try. I see in the some of the examples there are a few interceptors used. Is there any doc that explains what are required, what they do, and if there is any prescribed ordering to the interceptors? thanks Doug On 8/29/06, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > On Tue, 2006-08-29 at 20:22 +0000, Doug Lochart wrote: > > I decided to wrap the input stream that would do on the fly filtering. > > However you really need the entire content in memory to do proper > regular > > expressions and content filtering so > > I only want to read the entire entity at once if I am going to do > filtering. > > > > Anyway I thought I knew where I could put the code but it was never > > executing. It turns out (after looking further into the source) that > the > > entity is not really created until the > > doDeserialize() method is called (that is correct right?) > > > > In doService() I went out to the server and git the response. I then > > extracted the entity from that response, wrapped it with another > entity that > > will wrap the input stream and then > > set that entity into the response going back to the original client. > > > > I then look and it seems that after the call to doService() and > > postprocessResponse() a call to deserialize occurs and within there a > new > > Entity is created and populated. > > > > I am still learning the overall design and I don't have it all quite > yet (as > > is obvious) > > > > My question to you is: Is creating my own DefaultEntityDeserializer > the > > correct approach based on the way the code is designed or are there > other > > intercept points, wrap points that > > I can use that I have not yet uncovered? > > > > Hi Doug, > > The best approach is apply some sort of a transformation to all HTTP > requests or responses is to develop a custom protocol interceptor. > Protocol interceptors are very similar to Servlet filters. > > Take a look at these sample classes that implement transparent content > compression / decompression as a reference material: > > http://svn.apache.org/repos/asf/jakarta/httpcomponents/httpcore/trunk/src/contrib/org/apache/http/contrib/compress/ > > > For example, the ResponseGzipCompress.java interceptor wraps the > original response with GzipCompressingEntity.java, which compresses > response content on-fly. Its counterpart, the > ResponseGzipUncompress.java interceptors applies the reverse > transformation by wrapping the response entity with > GzipDecompressingEntity.java. > > In order to implement transparent content compression / decompression > one simply should add the ResponseGzipCompress.java interceptor to the > server side HTTP service and the ResponseGzipUncompress.java and > RequestAcceptEncoding.java interceptors to the client side HTTP executor > without having to change a single line of application code. > > Hope this helps > > Oleg > > > thanks > > > > 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?
-- What profits a man if he gains the whole world yet loses his soul?
