Yes, urllib3 supports automatic retries for failed connections and requests. This functionality is provided through the use of the Retry
class which can be configured to retry requests that fail due to specific types of exceptions, HTTP return codes, or even to respect certain HTTP headers like Retry-After
.
Here's how you can use automatic retries in urllib3:
- Import the required classes from
urllib3
. - Create an instance of
Retry
with the desired parameters. - Pass the
Retry
instance to aHTTPConnectionPool
orPoolManager
.
Here's an example in Python demonstrating how to set up automatic retries with urllib3:
import urllib3
from urllib3.util.retry import Retry
from urllib3 import PoolManager
# Define the retry strategy
retries = Retry(
total=5, # Total number of retries to allow.
read=5, # How many times to retry on read errors.
connect=5, # How many times to retry on connection errors.
backoff_factor=0.1, # A backoff factor to apply between attempts.
status_forcelist=[500, 502, 503, 504], # A set of HTTP status codes that we should force a retry on.
)
# Create a PoolManager with the retry strategy
http = PoolManager(retries=retries)
# Make a request
response = http.request('GET', 'http://example.com')
# Check the response
print(response.status)
print(response.data)
In this example, total
specifies the maximum total number of retries, read
is the maximum number of retries on read errors, connect
is the maximum number of retries on connection errors, and backoff_factor
is used to determine the delay between retry attempts as a function of the number of retries so far.
The status_forcelist
parameter is a list of HTTP status codes that should trigger a retry. If the server responds with one of these status codes, urllib3 will retry the request according to the rules set in the Retry
object.
The Retry
class also allows for more advanced configurations such as setting raise_on_status
to False if you don't want to raise an exception for HTTP error status codes, or raise_on_redirect
to False if you don't want to raise an exception when a redirect response is received.
Remember to always handle exceptions that might be raised by the request call, especially when dealing with network operations, as retries might not always solve all problems (e.g., a server might be permanently down or unreachable).