Loading ...
Sorry, an error occurred while loading the content.

Re: problems with XMLRPC and zope

Expand Messages
  • mrdamnfrenchy@yahoo.com
    Thanks Paul, adding $XMLRPC::Constants::DO_NOT_USE_CHARSET = 1; works great in all cases. I ll send this to zope-dev to get them to change the content-type
    Message 1 of 3 , Oct 12, 2001
      Thanks Paul,

      $XMLRPC::Constants::DO_NOT_USE_CHARSET = 1;
      works great in all cases.

      I'll send this to zope-dev to get them to change the content-type behavior.


      --- In soaplite@y..., Paul Kulchenko <paulclinger@y...> wrote:
      > Hi, Mathieu!
      > > and here is a header for the same request as generated by
      > > XMLRPC::Lite (which doesn't work):
      > >
      > > POST http://www.example.com/index.html
      > > Accept: text/xml
      > > Accept: multipart/*
      > > Content-Length: 108
      > > Content-Type: text/xml; charset=utf-8
      > This is the header that XMLRPC::Lite's debug shows, but it's not
      > exactly header that is presented on wire. Low-level LWP::Protocol
      > library modifies this information to satisfy requirements of used
      > protocols and as the result header on wire looks more like:
      > POST /RPC2 HTTP/1.0
      > Accept: text/xml
      > Accept: multipart/*
      > Host: betty.userland.com
      > Content-Length: 319
      > Content-Type: text/xml; charset=utf-8
      > Notice that Host header is present there. It's added by LWP::Protocol
      > even if it wasn't specified by application. HTTP/1.0 string is also
      > added. I think generated message is perfectly valid.
      > > The other problem is the "Content-type" line. Zope only recognizes
      > > a POST as an XML-RPC request if the content type is "text/xml", it
      > > thinks it's something else if the content is "text/xml;
      > > charset=utf-8". The xmlrpc specs say:
      > >
      > > The Content-Type is text/xml.
      > >
      > > So I'm not sure whether that's a Zope bug or a XMLRPC::Lite
      > > problem, but the spec doesn't mention "charset" anywhere, so I
      > > would tend to believe it's a XMLRPC::Lite problem.
      > I'm biased here, but the problem is that XMLRPC spec overrides HTTP
      > spec here. The reason is valid, make client as simple as possible,
      > but I don't think that requests, otherwise valid, should be rejected.
      > You may specify:
      > $XMLRPC::Constants::DO_NOT_USE_CHARSET = 1;
      > right after 'use XMLRPC::Lite' and charset will not be generated.
      > I will specify this option by default, to be fully compliant with
      > XMLRPC spec, and you'll be able to switch it off if needed.
      > Let me know if you still can't connect for any reason.
      > Best wishes, Paul.
    Your message has been successfully submitted and would be delivered to recipients shortly.