RE: HTTPAPI 1.9 pre3

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Sender: Scott Klement <klemscot@xxxxxxxxxxxx>


Hi Tom,

> When I tried your exact parameters with HTTP_TIMEOUT,
> I wait for 60 seconds and then I get the result data.

I understand.

> How do I get the debug file to work?

If you're running Pre3, the debug file should be automagically written to
/tmp/httpapi_debug.txt, because I accidentally left it turned on.

If it's turned off, though, you can enable it by editing CONFIG_H,
scrolling to the bottom of the member, and changing the settings there.
Then, once CONFIG_H has been changed, you need to recompile HTTPAPIR4


> It seems like the following logic should handle my situation.
>
>  C* if an error occurred, that might also signal the end of the
>  C*  data... but since web servers differ in how they disconnect
>  C*  us, we'll save the message -- but return success.
>  c                   eval      wwErr = errno
>  c                   if        wwLen<0 and wwErr <> EAGAIN
>  c                   callp     SetError(HTTP_RDRECV:'recvdoc: re
>  c                               %str(strerror(wwErr)) )
>  c                   return    wwRet
>  c                   endif
>
> The values of wwErr = 3406 and wwLen = -1
> Not sure what EAGAIN is set to but if it was 3406, then I think
> the code would work for me.

EAGAIN is a constant for the number 3406.

What this code does is try to receive data from the socket.  The recv()
API will return an EAGAIN response if there's no data there at the moment
(this is a non-blocking socket, so it will not wait for data to arrive.)
When it receives EAGAIN it knows that it has to wait for more data, so it
calls select() to wait until either that data arrives or until the timeout
elapses.

The question is: Is there more data to receive?

That piece of code is from the recvdoc() procedure.  The procedure should
be waiting until one of three events  (1) full document received, (2)
server disconnects us, (3) timeout occurs.

In the keywords that the server sent, there was a "content-length"
keyword.  It contains the number of bytes that we're supposed to receive
from the server.

The content-length is interpreted, and passed to the recvdoc() procedure
in the parameter peCLen.  recvdoc() keeps a count of the number of bytes
that it has received in the wwReceived variable.   So, it will keep
calling the recv() and select() APIs until either the timeout period
elapses, or until it receives as many bytes as are in the peCLen
parameter.

So, if you want to debug this yourself, take a look at the value of peCLen
and wwReceived at the time that you're getting the long pause.  Assuming
that wwReceived is smaller than peCLen, then recvdoc() is acting
appropriately by waiting for more data.

I'm really puzzled by the fact that this works great on my system, but not
on yours... I don't know what that could indicate.

One possible workaround is to use Connection: close.  Let me see if I can
find some example code for doing that, and I'll write another message.

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------