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

Re: [soapbuilders] IONA round 2 endpoint

Expand Messages
  • 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 1 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 2 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 3 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.