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

Re: [radio-dev] Re: Macro TCP error

Expand Messages
  • Jeremy Bowers
    ... OK, here s what s failing: According to the HTTP specification section 2.2 (ftp://ftp.isi.edu/in-notes/rfc2616.txt), HTTP served documents use a CRLF to
    Message 1 of 8 , Apr 30 2:38 PM
    • 0 Attachment
      colinfaulkingham wrote:
      > Please, be my guest!
      >
      > Thanks,
      > Colin Faulkingham

      OK, here's what's failing: According to the HTTP specification section
      2.2 (ftp://ftp.isi.edu/in-notes/rfc2616.txt), HTTP served documents use
      a CRLF to delimit the end of a line. A blank line is sent before the
      content of the HTML document is sent. Thus, Radio waits for a CR LF CR
      LF to see that the headers have finished coming, so it can process them.
      It does so by calling tcp.readStreamUntil
      (http://docserver.userland.com/tcp/readStreamUntil).

      However, your webserver is only sending LF's, which is a violation of
      the spec. This causes the tcp.readSteamUntil to become upset that the
      stream was closed before it saw the pattern it was looking for, causing
      the error you saw.

      That Perl worked as a client is technically a flaw in its
      implementation; it should not, any more then Radio does. Furthermore,
      reading the specs, it looks like that's a Perl script serving that page
      emitting the linefeeds... that's a MAJOR spec violation in that case.

      Of course SOAP::Lite happily reads SOAP::Lite's non-standard output... ;-)

      The solution to this is to fix your webserver's output somehow.

      Also, there's something wrong with the script call, it's giving an
      error. It could be the faked parameters, and it may be what you were
      expected. It's probably easy to fix, once you get things working
      correctly at the protocol level.
    • colinfaulkingham
      Wow! Thanks, The server is actually IIS 5.0 running Active State s PerlEx which is a mod_perl type accelerator. I will look into this problem with active
      Message 2 of 8 , Apr 30 3:35 PM
      • 0 Attachment
        Wow! Thanks,
        The server is actually IIS 5.0 running Active State's PerlEx which is
        a mod_perl type accelerator. I will look into this problem with
        active state and see what's up.

        As far as the call being wrong the soap::Lite module returned the
        exactly what it was supposed to maybe I gave you a misspelled version
        or something. I will check it out.

        Thanks again your help is very much appreciated.
        Colin

        --- In radio-dev@y..., Jeremy Bowers <jerf@j...> wrote:
        > colinfaulkingham wrote:
        > > Please, be my guest!
        > >
        > > Thanks,
        > > Colin Faulkingham
        >
        > OK, here's what's failing: According to the HTTP specification
        section
        > 2.2 (ftp://ftp.isi.edu/in-notes/rfc2616.txt), HTTP served documents
        use
        > a CRLF to delimit the end of a line. A blank line is sent before
        the
        > content of the HTML document is sent. Thus, Radio waits for a CR LF
        CR
        > LF to see that the headers have finished coming, so it can process
        them.
        > It does so by calling tcp.readStreamUntil
        > (http://docserver.userland.com/tcp/readStreamUntil).
        >
        > However, your webserver is only sending LF's, which is a violation
        of
        > the spec. This causes the tcp.readSteamUntil to become upset that
        the
        > stream was closed before it saw the pattern it was looking for,
        causing
        > the error you saw.
        >
        > That Perl worked as a client is technically a flaw in its
        > implementation; it should not, any more then Radio does.
        Furthermore,
        > reading the specs, it looks like that's a Perl script serving that
        page
        > emitting the linefeeds... that's a MAJOR spec violation in that
        case.
        >
        > Of course SOAP::Lite happily reads SOAP::Lite's non-standard
        output... ;-)
        >
        > The solution to this is to fix your webserver's output somehow.
        >
        > Also, there's something wrong with the script call, it's giving an
        > error. It could be the faked parameters, and it may be what you
        were
        > expected. It's probably easy to fix, once you get things working
        > correctly at the protocol level.
      Your message has been successfully submitted and would be delivered to recipients shortly.