[EMAIL PROTECTED] wrote: >If the intent is for the HTTP client component by the Apache group to be >the single entry point on the client side, I'm all for it. It has been >tedious to maintain two sets of similar changes between XmlRpcClient and >XmlRpcClientLite. While the interceptors patch may be large, the patch I >posted yesterday is smaller and includes code which accumulates and reads >headers on both the client (both clients) and server side. Does Apache >have an HTTP server component that also returns headers? It's all fine >and good to be able to modify headers on the client side...but something >needs to read them on the server side also. You are right, the >headers/XmlRpcRequest issue, introspection, and interceptors are somewhat >orthogonal...it just so happened that code in my interceptors patch also >added the ability for modification of headers...this can of course be done >independently of interceptors. > >Aaron Hamid >
Well I have been careful not to modify the XmlRpcClientLite class because I am not familiar with the goals of it. I am making modifications exclusively to XmlRpcClient. The best I have been able to find in Apache's software for a java HTTP Server component is in Tomcat: the Catalina connector package. In my current project, the XML-RPC server I am using already supports (and in fact requires!) HTTP/1.1 chunking, compression, and cookies. Obviously it will be advantageous for this library to support these things too, but this will be separate from the client process. Understand, there is more to this than just custom headers. I am starting to "get" this interceptor thing... and it sounds like a good idea. I just think it will be kind of a "hack" to do HTTP headers with it. -- Ryan Hoegg ISIS Networks
