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

IONA round 2 endpoint

Expand Messages
  • Simon Fell
    Hi, I m hitting the IONA round 2 server, but all i get back is a 400 bad request error, here s a wire dump POST
    Message 1 of 10 , Jun 1, 2002
    • 0 Attachment
      Hi,

      I'm hitting the IONA round 2 server, but all i get back is a 400 bad
      request error, here's a wire dump

      POST /xmlbus/container/InteropTest/BaseService/BasePort HTTP/1.1
      Content-Type: text/xml; charset=UTF-8
      User-Agent: PocketSOAP/1.3.2
      Accept-Charset: UTF-8, UTF-16;q=0.8, iso-8859-1;q=0.8
      Host: interop.xmlbus.com:7002
      Content-Length: 435
      SOAPAction: "http://soapinterop.org/"

      <S:Envelope
      S:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
      xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
      xmlns:a="http://soapinterop.org/"
      xmlns:XS="http://www.w3.org/2001/XMLSchema"
      xmlns:XI="http://www.w3.org/2001/XMLSchema-instance">
      <S:Body><a:echoString><inputString XI:type="XS:string">Some ASCII
      string that needs echoing back please <g></inputString>
      </a:echoString>
      </S:Body></S:Envelope>

      HTTP/1.1 400 Bad Request
      Date: Sun, 02 Jun 2002 04:41:31 GMT
      Server: ART 1.0
      Connection: close


      Thanks
      Simon
    • Daniel Kulp
      Simon, ... We upgraded the server on Friday and this may be a result. I just tried hitting it with our clients and everything seems OK. Could you try it
      Message 2 of 10 , Jun 3, 2002
      • 0 Attachment
        Simon,

        > I'm hitting the IONA round 2 server, but all i get back is a 400 bad
        > request error, here's a wire dump


        We upgraded the server on Friday and this may be a result. I just tried
        hitting it with our clients and everything seems OK. Could you try it
        again?

        If it still fails, could you send me the raw wire dumps (without mangling
        of CR/LF things and such that email clients and yahoogroups tend to do)?

        Thanks!

        --
        J. Daniel Kulp
        Principal Engineer
        IONA
        END 2 ANYWHERE
        P: 781-902-8727 C: 617-513-4582 F:781-902-8001
        daniel.kulp@...
      • Simon Fell
        ... 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
        Message 3 of 10 , Jun 5, 2002
        • 0 Attachment
          On Mon, 3 Jun 2002 10:22:02 -0400, in soap you wrote:

          >
          >Simon,
          >
          >> I'm hitting the IONA round 2 server, but all i get back is a 400 bad
          >> request error, here's a wire dump
          >
          >
          >We upgraded the server on Friday and this may be a result. I just tried
          >hitting it with our clients and everything seems OK. Could you try it
          >again?
          >
          >If it still fails, could you send me the raw wire dumps (without mangling
          >of CR/LF things and such that email clients and yahoogroups tend to do)?
          >
          >Thanks!

          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.

          Cheers
          Simon
          www.pocketsoap.com
        • Vincent MATHIEU
          Hi, I m using soaplite as service Web, and nusoap as a customer. I encounter two problems with the detail item of the fault object: 1) this item is coded
          Message 4 of 10 , Jun 5, 2002
          • 0 Attachment
            Hi,

            I'm using soaplite as service Web, and nusoap as a customer.
            I encounter two problems with the 'detail' item of the fault object:

            1) this item is coded <detail> with soaplite, and <faultdetail> with nusoap. nusoap thus does not recover this information.

            2) If I write numerical character strings in item the detail, it is systematically transformed into integer by soaplite.
            Example with the value "12":
            <detail xsi:type="xsd:int">12</detail>

            How to make to force a value of the string type?

            thank's

            Vincent


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

          • 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 5 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 6 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 7 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 8 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 9 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 10 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.