Socket host that does not terminate response with a CRLF.

[Eduard Sluis <eduard@xxxxxxxxxxxxxxxxxxxxxxx>]

   Hi Scott,

   Ok, we are using the capacities of FTPAPI to create a TCPIP Socket
   Interface.
   We have many like that already.
   We normaly are the client so we will create the format that must be
   communicated and send that to the host.
   C     ' '           CHECKR    BUF           $H05N0
   C                   EVAL      RC = send(TCP:%ADDR(BUF):$H05N0:
   C                             peFlags)

   Than we wait untill there is something available in the buffer.
    *
    * Check if the network buffer contains something.
    *----------------------------------------------------------------
    * create a timeval struct, set it to 00.5 seconds:
   C                   eval      tv_len = %size(timeval)
   C                   alloc     tv_len        tv
   C                   eval      p_timeval = tv
   C                   eval      tv_sec = 00
   C                   eval      tv_usec = 500000
   C                   callp     FD_ZERO(readset)
   C                   callp     FD_SET(TCP: readset)
    * call select.
   C                   eval      rc = select(TCP+1: %addr(readset):
   c                                    *NULL: *NULL:
   c                                    p_timeval)

   And if that is the case we will receive that.
   C                   EVAL      RC = tcp_recv(TCP: buf)
   C     ' '           CHECKR    BUF           $H05N0
   C                   CALLP     ToEBCDIC(BUF:$H05N0)

   The tcp_recv is expecting a CRLF that in this case is not provided by
   the host.

   Kind regards,
   Eduard Sluis.
     _________________________________________________________________

   From: Scott Klement <sk@xxxxxxxxxxxxxxxx>
   To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
   Sent: Fri, July 9, 2010 3:17:19 PM
   Subject: Re: Socket host that does not terminate response with a CRLF.
   Hi Eduard,
   Glad to see that you were able to get your message to post to the
   mailing list!
   > We are using FTPAPI and HTTPAPI already for a long time to create
   > interfaces to different external systems.
   > Now for the first time we stumbled on one that does not terminate
   the
   > response with a CRLF.
   I'm not following this.  What sort of response are we talking about?
   Is
   this a file downloaded with FTPAPI or HTTPAPI?  Or is this an HTTP
   keyword?  Or are we talking about a custom TCP-based protocol? Or what
   is this, exactly?
   > They seems to be reluctant to change that and argue that we should
   > make use of the prefixed length (in Unsigned short 16 bit endian
   order
   > format (we also have problem in creating that prefix in the
   request)).
   > I understood that the CRLF is part of the standard but are not
   > completely sure of.
   Which standard are you referring to, here?  If this is a socket
   program,
   then which TCP/IP protocol are you implementing?  (If it's your own
   custom protocol, then obviously there's no existing standard!)
   Or is this a file download, and if so, what format is the file
   supposed
   to be in?  What standard does that file format adhere to?
   > If part of the standard we should be able to make them adhere to it.
   > What alternatives are available if we can not make them change their
   > part??
   I really need more information about your scenario to even attempt to
   answer that.  You mention both HTTPAPI and FTPAPI in your message, but
   you don't say which one you're using, or even if you're using them for
   this project.  You don't say which part of the transaction has the
   missing CRLF.
   Can you please explain the scenario better?  And provide an example?
   Thanks.
   ----------------------------------------------------------------------
   -
   This is the FTPAPI mailing list.  To unsubscribe, please go to:
   http://www.scottklement.com/mailman/listinfo/ftpapi
   ----------------------------------------------------------------------
   -

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------