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

Re: [soaplite] problems with XMLRPC and zope

Expand Messages
  • Paul Kulchenko
    Hi, Mathieu! ... 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
    Message 1 of 3 , Oct 12, 2001
    • 0 Attachment
      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.

      --- mrdamnfrenchy@... wrote:
      > I found out that XMLRPC::Lite doesn't work with zope. However, the
      > code generated by Frontier::Client works.
      >
      > There a few issues, to explain that, here is a header from
      > Frontier::Client (which works):
      >
      > POST /index.html HTTP/1.0
      > Host: www.example.com
      > User-Agent: libwww-perl/5.53
      > Content-Length: 105
      > Content-Type: text/xml
      >
      > 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
      >
      > The XML is more or less the same for both request (new lines in the
      > Frontier version), so I won't discuss it.
      >
      > To test this, I used a couple of configuration:
      > - connect directly to the zope server
      > - connect to zope through a Apache/FastCGI gateway
      > - connect to zope through Apache using a URL rewrite
      > (for virtual hosting)
      >
      > With telnet, I started modifying the headers until SOAP::Lite
      > succeeded. Here is what I found:
      >
      > The first line (POST...) is a problem. Zope does not support
      > receiving a full URI (this is probably a Zope bug). Zope also
      > requires the HTTP version string. Using the construct:
      >
      > POST /index.html HTTP/1.0
      > Host: www.example.com
      >
      > Seems to work for both Zope and Apache. This works with Apache but
      > not zope:
      >
      > POST http://www.example.com/index.html HTTP/1.0
      >
      > Apache only accepts a full URL on Post if HTTP/1.0 is present.
      >
      > 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.
      >
      > -Mathieu
      >
      >
      >
      >
      > ------------------------ Yahoo! Groups Sponsor
      >
      > To unsubscribe from this group, send an email to:
      > soaplite-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      >
      >


      __________________________________________________
      Do You Yahoo!?
      Make a great connection at Yahoo! Personals.
      http://personals.yahoo.com
    • 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 2 of 3 , Oct 12, 2001
      • 0 Attachment
        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 behavior.

        -Mathieu


        --- 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.