[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Error in parsing XML
Hello Scott,
Your solution works, however, I don't think it is completely correct.
The debug list now shows
SetError() #44: CommSSL_read: connection broken
while I think that that is not the case. The connection is not broken,
but the file is at its end. That is not an error situation, but the
normal flow of events.
Moreover, this error is not processed as an error (it only shows on
the debug). When there is a real error, this error would also not be
processed.
Regards, Wilbert
On 8/20/07, Scott Klement <[1]klemscot@xxxxxxxxxxxx> wrote:
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:
[2]http://www.scottklement.com/mailman/listinfo/ftpapi
-------------------------------------------------------------------
----
References
1. mailto:klemscot@xxxxxxxxxxxx
2. 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
-----------------------------------------------------------------------