Re: Error in parsing XML

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Hello Wilbert,

> In case peUseCL is *off there is no escape from the subprocedure when
> the last read string (wwLen) has a length if 0.

peUseCL means "Use Content-Length".  It's purpose is to tell recvdoc() 
whether the content-length (passed in the peCLen parameter) should be 
used to detect the end of the download, or whether it should keep 
receiving until the server has disconnected the TCP connection.

In HTTP/1.1 the server is supposed to either send a 'Content-Length' 
header (to indicate how many bytes of data to download) ot else it's 
supposed to use "chunked" encoding (in which case, recvchunk() would be 
called instead of recvdoc()).

However, for backward compatibility with older versions of the HTTP 
protocol, there's also the capability to simply receive data you're 
disconnected.

So, HTTPAPI checks for a content-length header.  If one is set, it turns 
peUseCL on... HTTPAPI then receives data until it gets exactly as many 
bytes as were specified in the peCLen parameter.  If it doesn't receive 
that many, it returns -1 to indicate failure.  If peUseCL is off (the 
server didn't sent 'content-length') it receives until a network error 
occurs, and doesn't consider the network error to be a failure.   That's 
the purpose of peUseCL.

You say that recvdoc() should exit when it receives a string of length 
0.   On that point, I disgree.

recvdoc() calls comm_read() to receive data.  Comm_read is mapped (using 
a procedure pointer) to either CommTCP_read() or CommSSL_Read() 
depending on whether the connection is using SSL.

Comm_Read() should NEVER return 0.   If you look at the code for 
CommTCP_Read(), you'll see that, in fact, it never does return 0.

However, CommSSL_Read() can potentially return 0 -- and that's the bug. 
  It shouldn't, but it does.

Try this:   Open up the COMMSSLR4 source member and look for the call to 
gsk_secure_soc_read().   There should only be one place that it's 
called, and it should be in the CommSSL_Read() subprocedure.

Immediately after the gsk_secure_soc_read() call, insert the following code:

   c                   if        rc=GSK_OK and wwLen=0
   c                   callp     SetError(HTTP_BRRECV:'CommSSL_read: '+
   c                               ' connection broken')
   c                   return    -1
   c                   endif


This will cause CommSSL_read() to return an error when wwLen=0 (which is 
what it *should* do) so that recvdoc() will work correctly.

Please try it and let me know if it solves the problem.  I need to know 
if it works because I have no way of reproducing the problem here, so I 
can't test it.

If it works, I'll put an updated copy of httpapi on my web site...
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------