timeout is double what it should be.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. create a simple cgi script that sleeps for 30 seconds:
import time
time.sleep(30)
or using php:
<?php sleep(30);?>
2. Execute this script:
import time
import socket
import httplib2
import socket
for t in range(1,30):
    #socket.setdefaulttimeout(t)
    http=httplib2.Http(timeout=t)
    start=time.time()
    try:
        http.request("http://localhost/qa/sleepy.php")
    except socket.timeout:
        print("Timeout:"+str(t))
        print("Actual Time:"+str(time.time()-start))

What is the expected output? What do you see instead?
This is HTTPLib2:
Timeout:1
Actual Time:2.01092815399
Timeout:2
Actual Time:4.00687503815
Timeout:3
Actual Time:6.00952100754
Timeout:4
Actual Time:8.00838899612
Timeout:5
Actual Time:10.0043568611
Timeout:6
Actual Time:12.0086779594
Timeout:7
Actual Time:14.0134260654
Timeout:8
Actual Time:16.0041809082

This is HTTPlib from the python core:
Timeout:1
Actual Time:1.00176405907
Timeout:2
Actual Time:2.00329780579
Timeout:3
Actual Time:3.00409197807
Timeout:4
Actual Time:4.00118494034
Timeout:5
Actual Time:5.00267291069

What version of the product are you using? On what operating system?
Python 2.7 on an Ubuntu 10.10. I think httplib2 came from apt. 

Please provide any additional information below.
The same problem happens if you use socket.setdefaulttimeout() with httplib2.  
However if you use socket.setdefaulttimeout() with httplib it works as it 
should. 

Original issue reported on code.google.com by firealwa...@gmail.com on 5 Jan 2011 at 12:53

[GoogleCodeExporter]

Unfortunately the code has been like that for a long time where it 
automatically retries once on a failed connect. I am worried about making a 
change here breaking existing code that depends on the current behavior.

Original comment by joe.gregorio@gmail.com on 13 Feb 2011 at 5:05

• Changed state: WontFix

[GoogleCodeExporter]

Actually it broke my code because I needed an exact timeout.  I was forced to 
switch to httplib.   Based on this response I will never use httplib2.   An API 
shouldn't lie to its programmers. 

Original comment by firealwa...@gmail.com on 13 Feb 2011 at 5:24

[GoogleCodeExporter]

Issue 109 has been merged into this issue.

Original comment by joe.gregorio@gmail.com on 13 Feb 2011 at 5:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I think the best path would be to make the retries configurable, and default it 
to the current behavior of 2 tries.  Wouldn't that satisfy everyone?  

I've made a simple patch: http://codereview.appspot.com/4365054/

Original comment by ned...@gmail.com on 11 Apr 2011 at 2:23

[GoogleCodeExporter]

That is bad behavior default behavior.  I am building a testing framework with 
HTTP,  if you magically fire off 2 http requests or double the timeout my tests 
will magically fail.

Original comment by firealwa...@gmail.com on 11 Apr 2011 at 4:15

[GoogleCodeExporter]

@firealwa...: if this were a new library, I would agree with you: the default 
should be no retries.  But Joe has a point: this library has been in wide use 
with the default of 2.  Keeping it is not difficult, and my patch will give you 
the control you need to disable the retries.

Original comment by ned...@gmail.com on 11 Apr 2011 at 7:34

[GoogleCodeExporter]

Is there any chance nedbat's patch will be integrated into the core library?

My organization uses httplib2 to request resources that can be computationally 
intensive. If the request times out, it's probably because it's still busy 
calculating the response. In those cases the last thing we want to do is issue 
another request, which will start another instance of the calculations.

I understand leaving the behavior as it is, though I do think documentation 
should be updated to clearly indicate that requests will be retried. I really 
hope to see nedbat's patch integrated into the main branch so that we do not 
have to maintain a separate branch of httplib2. Having an unconfigurable retry 
makes httplib2 unusable for our purposes without the patch.

Original comment by aus...@gmail.com on 18 Jul 2011 at 4:05

[GoogleCodeExporter]

Please reopen and apply the patch provided.

It is not reasonable to have a hard-coded retry. I happened to run into this 
today when some other code had set socket's default timeout to 5 second. This 
resulted in two POSTs going out and both failing with a socket.timeout 
exception because it took more than 5 seconds to read the first byte. Removing 
the 5 second timeout fixed things of course, but I was *really* surprised to 
see two requests go out.

Original comment by bhiggins on 22 Nov 2011 at 12:23

[GoogleCodeExporter]

Please for the love of god at least apply the patch to make it configurable if 
you don't want to change the default.

This is the only HTTP library I know of that has this behavior and every time I 
run into an issue caused by this it takes me forever to figure it out, because 
I would never expect a HTTP library to retry by default. This time I got a nice 
nonce_already_used from an OAuth 1 API because of the retry behavior and an 
request that timed out.

Original comment by florian....@gmail.com on 8 Mar 2012 at 10:43

[GoogleCodeExporter]

Please apply the patch.  What florian said.  Very confusing behaviour, but 
worse that there's no way to turn it off.  Argh.

Original comment by boulton.rj@gmail.com on 3 Apr 2012 at 4:36

[GoogleCodeExporter]

Fixed in 
http://code.google.com/p/httplib2/source/detail?r=a0d2b4b2f1357659bbdf9d257a053c
a82ac49272

Original comment by joe.gregorio@gmail.com on 17 Apr 2012 at 4:42

• Changed state: Fixed

[GoogleCodeExporter]

Any chance we can get an official release with this fix in it?

Original comment by aus...@gmail.com on 20 Jun 2012 at 10:13