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

Re: [soapbuilders] soaplite, nusoap and Faults

Expand Messages
  • rjray@blackperl.com
    (Please try to not send mail as HTML only, at least configure your mail agent to offer multipart/alternative. It makes it very difficult to effectively quote
    Message 1 of 10 , Jun 5, 2002
    • 0 Attachment
      (Please try to not send mail as HTML only, at least configure your mail agent
      to offer multipart/alternative. It makes it very difficult to effectively
      quote any relevant text in a reply.)

      You don't offer the code that runs with SOAP::Lite, but from what you say, I
      can offer this: you can force the type of data items in SOAP::Lite by using
      the SOAP::Data class directly, rather than passing raw data and having
      SOAP::Data guess the type from examination of the string. As you note, "12"
      looks like an int, so it gets typed as xsd:int. If instead you passed:

      SOAP::Data->name->(a => 12)->type('string')

      You would get:

      <a xsi:type="xsd:string">12</a>

      (Of course, substitute the real parameter name for "a".)

      Randy
      --
      """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
      Randy J. Ray rjray@...
      Campbell, CA rjray@...
      <A HREF="http://www.svsm.org">Silicon Valley Scale Modelers</A>
    • rjray@blackperl.com
      ... rjray SOAP::Data- name- (a = 12)- type( string ) Slight correction. Should read: SOAP::Data- name(a = 12)- type( string ) Randy --
      Message 2 of 10 , Jun 6, 2002
      • 0 Attachment
        >>>>> "rjray" == rjray <rjray@...>
        >>>>> wrote the following on Wed, 05 Jun 2002 23:54:28 -0700

        rjray> SOAP::Data->name->(a => 12)->type('string')

        Slight correction. Should read:

        SOAP::Data->name(a => 12)->type('string')

        Randy
        --
        """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
        Randy J. Ray rjray@...
        Campbell, CA rjray@...
        <A HREF="http://www.svsm.org">Silicon Valley Scale Modelers</A>
      • Vincent MATHIEU
        ... Thank s. But, how can I do the same think with the fault message, item ? -- Vincent MATHIEU CRI - Universite NANCY 2 | Email :
        Message 3 of 10 , Jun 6, 2002
        • 0 Attachment
          Surlignage rjray@...:

          > >>>>> "rjray" == rjray <rjray@...>
          > >>>>> wrote the following on Wed, 05 Jun 2002 23:54:28 -0700
          >
          > rjray> SOAP::Data->name->(a => 12)->type('string')
          >
          > Slight correction. Should read:
          >
          > SOAP::Data->name(a => 12)->type('string')
          >

          Thank's.
          But, how can I do the same think with the fault message, item <detail>?

          --
          Vincent MATHIEU
          CRI - Universite NANCY 2 | Email : Vincent.Mathieu@...
          Pole Lorrain de Gestion | Tel : (33) 03.83.39.64.06
          13, Rue Michel Ney - C.O. 75 | Fax : (33) 03.83.39.64.43
          54013 Nancy Cedex. FRANCE
        • Daniel Kulp
          Simon, ... Well, there are two problems, one on your end and a big one on ours: Your end: the Content-Length header is off. I count 244 characters (including
          Message 4 of 10 , Jun 6, 2002
          • 0 Attachment
            Simon,

            > Daniel, I'm still seeing this problem, I've attached the following
            > 1) a raw ethereal capture of exchange [iona.libpcap]
            > 2) a copy of the captured complete request [iona_req.txt]
            > 3) a copy of the captured complete response [iona_res.txt]
            >
            > You should be able to load the raw capture into tcpdump or ethereal to
            > look at the exact packet exchanges.

            Well, there are two problems, one on your end and a big one on ours:

            Your end: the Content-Length header is off. I count 244 characters
            (including CR and LF) for the content, not 223. However, that should
            result in a parse exception (not all the XML is there), not the error you
            are seeing. I snagged the bytes out of the libpcap and pretty much
            counted.

            Our end: there seems to be a bug in our app server that barfs if the
            headers and content are EXACTLY split accross two packets with the
            complete headers in one and the content in the other. In your case, if I
            take your data and do:
            out.write(bt,0,281);
            out.flush();
            out.write(bt,281,bt.length-281);
            out.flush();
            it fails with the same error you see. Any value other than 280 or 281
            seems to work fine. (281 is the cuttoff at the end of the headers)

            Anyway, if you change your client to not flush the stream immediately
            after the headers, you should be all set. However, this is a bug on our
            side so I wouldn't expect a change from you.

            Thanks!

            --
            J. Daniel Kulp
            Principal Engineer
            IONA
            END 2 ANYWHERE
            P: 781-902-8727 C: 617-513-4582 F:781-902-8001
            daniel.kulp@...
          • simonfell99
            Thanks Daniel. I can t see the content-length problem though, I doubled checked and still get 223. Were you using ethereal to examine the dump or just looking
            Message 5 of 10 , Jun 6, 2002
            • 0 Attachment
              Thanks Daniel.

              I can't see the content-length problem though, I doubled checked and
              still get 223. Were you using ethereal to examine the dump or just
              looking at the raw file ?, if you look at the raw file, then it also
              contains data from the TCP & IP headers, which you may be counting.

              I might temporarly fold the writes into a single buffer [i thought
              that naggling would do this anyway], but I plan to move to using
              expect: 100-continue at some point, so in this case it will always
              send the headers on there own first.

              Cheers
              Simon

              --- In soapbuilders@y..., Daniel Kulp <daniel.kulp@i...> wrote:
              >
              > Simon,
              >
              > > Daniel, I'm still seeing this problem, I've attached the following
              > > 1) a raw ethereal capture of exchange [iona.libpcap]
              > > 2) a copy of the captured complete request [iona_req.txt]
              > > 3) a copy of the captured complete response [iona_res.txt]
              > >
              > > You should be able to load the raw capture into tcpdump or
              ethereal to
              > > look at the exact packet exchanges.
              >
              > Well, there are two problems, one on your end and a big one on ours:
              >
              > Your end: the Content-Length header is off. I count 244
              characters
              > (including CR and LF) for the content, not 223. However, that
              should
              > result in a parse exception (not all the XML is there), not the
              error you
              > are seeing. I snagged the bytes out of the libpcap and pretty much
              > counted.
              >
              > Our end: there seems to be a bug in our app server that barfs if
              the
              > headers and content are EXACTLY split accross two packets with the
              > complete headers in one and the content in the other. In your
              case, if I
              > take your data and do:
              > out.write(bt,0,281);
              > out.flush();
              > out.write(bt,281,bt.length-281);
              > out.flush();
              > it fails with the same error you see. Any value other than 280 or
              281
              > seems to work fine. (281 is the cuttoff at the end of the headers)
              >
              > Anyway, if you change your client to not flush the stream
              immediately
              > after the headers, you should be all set. However, this is a bug on
              our
              > side so I wouldn't expect a change from you.
              >
              > Thanks!
              >
              > --
              > J. Daniel Kulp
              > Principal Engineer
              > IONA
              > END 2 ANYWHERE
              > P: 781-902-8727 C: 617-513-4582 F:781-902-8001
              > daniel.kulp@i...
            • Daniel Kulp
              ... Oops. My fault. Editor expanded tabs to spaces. (hate tabs) That would obviously inflate the content length. :) -- J. Daniel Kulp Principal Engineer
              Message 6 of 10 , Jun 6, 2002
              • 0 Attachment
                > I can't see the content-length problem though, I doubled checked and
                > still get 223. Were you using ethereal to examine the dump or just
                > looking at the raw file ?, if you look at the raw file, then it also
                > contains data from the TCP & IP headers, which you may be counting.

                Oops. My fault. Editor expanded tabs to spaces. (hate tabs) That would
                obviously inflate the content length. :)


                --
                J. Daniel Kulp
                Principal Engineer
                IONA
                END 2 ANYWHERE
                P: 781-902-8727 C: 617-513-4582 F:781-902-8001
                daniel.kulp@...
              Your message has been successfully submitted and would be delivered to recipients shortly.