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

Re: HTTPAPI too fast?



Scott,
 
This extra timeout works great so far,
 
Thanks, Wilbert

 
On 9/1/05, ian <ian@xxxxxxxxxxxxxxxxx> wrote:
Sender: "ian" <ian@xxxxxxxxxxxxxxxxx>

Re Scott's comments on '100 Continue'

On the server we connect to using HTTPAPI, we always get a "HTTP/1.1 200 OK"
after every POST and GET

How would this affect HTTPAPI ?

(I am still using 1.10)

Regards,

Ian Patterson


-----Original Message-----
From: owner-ftpapi@xxxxxxxxxxxxx [mailto:owner-ftpapi@xxxxxxxxxxxxx]On
Behalf Of Scott Klement
Sent: 31 August 2005 23:39
To: ftpapi@xxxxxxxxxxxxx
Subject: Re: HTTPAPI too fast?


Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx >


> Hello group, Another problem is this: HTTPAPI fails with only garbage in
> the error message. I can't debug this to find the command that fails,
> because in debug mode all runs well. Therefore I think that the cause of
> this message is that HTTPAPI somewhere doesn't wait for an answer long
> enough and jumps to conclusions..... Another question: why does
> CommSSL_Read time out? I am using 1.2. Version 1.1 had the same problem.

According to the HTTP spec, a web server is supposed to send a "100
Continue" response when a POST request is issued.  However, the spec says
that, for the sake of older web servers, a program that's issuing a POST
request has to be prepared to "time-out" if it doesn't receive the "100"
response, and continue anyway.

(Frankly, this was a bad idea by the people who created the spec. If the
100 isn't required, then it serves absolutely no purpose and shouldn't
have been added in the first place!)

But, unfortunately, it was.   Now, some servers send a "100 Continue"
response, and some do not.  In order to work with both types of servers,
HTTPAPI will only wait for 1/2 second before giving up.

Why such a short amount of time?  Because for servers that don't send this
response, HTTPAPI has to wait for it to timeout.  This slows down people's
POST requests, which is undesirable.

On the other hand, that short amount of time also means that if the
connection is running slowly, you might receive a "100 Continue" *AFTER*
the timeout has already happened (which is what I think is happening to
you, Wilbert)

In version 1.11 of HTTPAPI, I added a new API that can help solve these
problems, called http_set_100_timeout().  You can call this API to
increase or decrease the timeout for the "100 Continue" responses, so if
you know that your server DOES issue them, you can wait a little longer.
If you know that it doesn't, there's no reason to wait at all.

To use it, add code similar to the following that runs before you call
http_url_post (or post_raw, or post_xml, or whatever)

      // wait up to 5 seconds for a 100-continue response:
      http_Set_100_timeout(5);

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


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