[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HTTPAPI



Hi Ron,

> We are using the post procedure http_url_post_raw In looking at the
> code in there it is using the timeout for both the call to 
> http_persist_open and to http_persist_post

That's true, though instead of calling http_url_post_raw(), you could 
call http_persist_open() and http_persist_post() yourself.  (These 
routines are intended to be available to anyone to call).   That way you 
could set a timeout individually for the connects vs. the data transfer.

Though I wonder why you'd want to.


> I think I asked the question wrong here We are not having an issue
> with the connect timeout but with the post not waiting for a process
> to complete.

The timeout isn't the time it waits for the POST process to complete. 
It's the amount of idle time that's allowed before HTTPAPI gives up.

For example, let's say you have the timeout set to 30 seconds.  The 
total time of the POST can take hours or even days to complete, as long 
as HTTPAPI sends/receives at least one byte every 30 seconds.

If absolutely no sends/receives are able to be made for 30 seconds 
straight, then HTTPAPI gives up and says the connection is timed out.

Once again, if you think that the timeout provided is too short, set it 
to something like 86400.  Surely if it waits an entire DAY and hasn't 
received a single byte, something is wrong?


> Also I noticed in looking thru the code that the timeout variable
> type is defined as an Integer 10i 0 in http_url_post_raw and
> http_persist_open Then in the comm_connect prototype it is defined as
> 10P 3

Yes, that's true.  That means that you effectively can only pass a 
7-digit number for the timeout value (and can't use the full 10i 0 value).

That means that the largest timeout you can set is about 115.5 days.  I 
can't imagine you ever saying that you want to wait longer than that.  I 
think if your application can't send at least one byte every 4 months, 
something is seriously wrong.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------