[Zope] xmlrpc and fastcgi on IIS

[Marco Catunda]

Dieter,

	I don't what is happen. But I think the problem
is on fastcgi or IIS. I did't try it at apache.

	I've debuged the Zope code, the main problem
is on the following code at ZPublisher/HTTPRequest.py:

       fs=FieldStorage(fp=fp,environ=environ,keep_blank_values=1)
        if not hasattr(fs,'list') or fs.list is None:
            # Hm, maybe it's an XML-RPC
            if (fs.headers.has_key('content-type') and
                fs.headers['content-type'] == 'text/xml' and
                method == 'POST'):
                # Ye haaa, XML-RPC!
                global xmlrpc
                if xmlrpc is None: import xmlrpc
                meth, self.args = xmlrpc.parse_input(fs.value)
                response=xmlrpc.response(response)
                other['RESPONSE']=self.response=response
                other['REQUEST_METHOD']='' # We don't want index_html!
                self.maybe_webdav_client = 0
            else:
                self._file=fs.file
        else:
            fslist=fs.list
            tuple_items={}
            lt=type([])
            CGI_name=isCGI_NAME
            defaults={}
            converter=seqf=None

	The first statement 'if' try to find a list attribute at
fs variable. At fastcgi xmlrpc request the list attribute is '[]', 
so this statement is false on xml-rpc request and Zope think
this is a html request. I don't know why in fastcgi xml-rpc 
request is '[]'.

--
Marco Catunda





On Fri, 2002-09-06 at 15:10, Dieter Maurer wrote:
> Marco Catunda writes:
>  > 	I have tried to use xmlrpc on fastcgi zope support at
>  > 	IIS. I think IIS doesn't pass correct headers to zope,
>  > 	so Zope understand the xmlrpc request as html request.
> As fas as I know, XML-RPC does not need any special headers
> beside the "Content-Type: text/xml". It is very unlikely, that
> it is stripped.
> 
>  > ...
>  > 	Is there other idea to resolve it?
> In my view, XML-RPC through fastcgi schould work.
> 
> What happens? In what way, does it not work for you?
> Maybe, a TCP-Logger (such as Shane's "tcpwatch") may help
> you to understand what goes wrong.