[Twisted-web] Accessing request object from a SOAPPublisher soap_ method

[Jonathan Blocksom]

Thanks for the reply, I've been meaning to post a followup with what I 
wound up doing, which is along the lines of your second suggestion.

I modified the SOAPPublisher class render() method so that if the 
calling convention was keywords it added a keyword "request" with the 
HTTP reqeust object as the value.  I did this before the arguments from 
the message are put into the dict so that if there happened to be an 
argument named request it would still be okay (assuming you didn't want 
to look at the request object).

But thinking about the problem got me to wonder if my method really 
should have access to the request object.  It seems to me that it breaks 
the encapsulation in a fairly bad way.  I'm curious if other SOAP 
libraries in other languages give access to the HTTP requests along with 
the message.

I wound up deciding that I would have the originator of the message send 
along the information instead of trying to gather it from the header. 
The information was just the IP address of the sender (although my app 
won't work across NAT firewalls now, but that's ok).

Jonathan

Donovan Preston wrote:
> 
> On Jul 7, 2005, at 10:26 AM, Jonathan Blocksom wrote:
> 
>> Hi, I've got a SOAPPublisher class with some published methods and  I 
>> was hoping to access the HTTP request object from within.   Anybody 
>> know how to do this?
> 
> 
> Unfortunately it doesn't look like it. If you look at the  
> SOAPPublisher.render method, it looks up the callable and then calls  it 
> (indirecting through maybeDeferred). The only place the request is  
> available is in the local namespace of render. So, you could:
> 
> 1) override render, stuff the request somewhere (like self), then get  
> it out in your method; you should only do this if threads are in no  way 
> involved. If there aren't any threads then it would be safe. Just  be 
> sure to get it out immediately and pass around what you got out  (for 
> example, don't return a deferred then look in self in a callback)
> 
> 2) use some horrible callframe hack to extract the request from the  
> caller's frame. This would have the advantage of being threadsafe,  but 
> you aren't using threads anyway -- right?
> 
> Itamar is the guy to talk to about SOAP and XMLRPC, but I guess he  
> doesn't read this list. If you want to have a cleaner way of doing  this 
> in the future, you should probably talk to him about it, either  on IRC 
> or through email or something.
> 
> Donovan
> 
> 
> _______________________________________________
> Twisted-web mailing list
> Twisted-web at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
>