xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ar...@cornell.edu
Subject Re: http headers
Date Thu, 12 Sep 2002 18:52:52 GMT

XmlRpcClientLite has a built-in "light" HTTP client implementation, which 
I presume is supposed to be lighter than the Apache or Sun HTTPClient.  
Headers themselves won't be that useful if you can't do something with 
them on the server side so there must be something analogous to read them 
off at the server side.  Interceptors (or filters, or hooks, whatever 
youw ant to call them, basically just a callback mechanims) only deals 
with mutating a call that is underway.  So yes, I'd expect you'd want to 
expose the headers functionality at the client end...through something 
like setHeaders()/setHeader()/getHeaders()/getHeader().  On the server 
side however, there is no server endpoint per se...the endpoint is your 
XMLRPC server class, so to make the headers available to your code (not 
just an interceptor) there would have to be some sort of mapping set up, 
probably based on thread, e.g.:

public class ContextMapping {
  private ContextMapping() {}
  private static Hashtable contexts = new Hashtable();

  public static void setContext(XmlRpcRequest req) {
    contexts.put(Thread.currentThread(), req);

  public static XmlRpcRequest getContext() {
    return contexts.get(Thread.currentThread());

  // would be necessary to remove mapping so threads don't
  // hang around; alternative is Weak references
  public static void clearContext() {

Server side interceptor or request parsing code:

// read request from socket
// create XmlRpcRequest with headers

Your XML-RPC server class:

public String saySomething(Vector arguments) {
  XmlRpcRequest theRequest = ContextMapping.getContext();
  String userAgent = theRequest.getHeader("User-Agent");
  String whatToSay = theRequest.getHeader("whatShouldISay");
  return "You called with " + arguments.size() + " arguments "
         + "with user agent: " + userAgent + ", and passed a "
         + "header that told me to say: " + whatToSay;

Obviously that is a completely contrived example.  The patch I posted 
yesterday would leave this possibility open.



arh14@cornell.edu 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 
>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

View raw message