Python HTTP library with thread-safe connection pooling, file post support, user friendly, and more.

Overview

urllib3

PyPI Version Python Versions Join our Discord Coverage Status Build Status on GitHub Build Status on Travis Documentation Status

urllib3 is a powerful, user-friendly HTTP client for Python. Much of the Python ecosystem already uses urllib3 and you should too. urllib3 brings many critical features that are missing from the Python standard libraries:

  • Thread safety.
  • Connection pooling.
  • Client-side SSL/TLS verification.
  • File uploads with multipart encoding.
  • Helpers for retrying requests and dealing with HTTP redirects.
  • Support for gzip, deflate, and brotli encoding.
  • Proxy support for HTTP and SOCKS.
  • 100% test coverage.

urllib3 is powerful and easy to use:

>>> import urllib3
>>> http = urllib3.PoolManager()
>>> r = http.request('GET', 'http://httpbin.org/robots.txt')
>>> r.status
200
>>> r.data
'User-agent: *\nDisallow: /deny\n'

Installing

urllib3 can be installed with pip:

$ python -m pip install urllib3

Alternatively, you can grab the latest source code from GitHub:

$ git clone git://github.com/urllib3/urllib3.git
$ python setup.py install

Documentation

urllib3 has usage and reference documentation at urllib3.readthedocs.io.

Contributing

urllib3 happily accepts contributions. Please see our contributing documentation for some tips on getting started.

Security Disclosures

To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure with maintainers.

Maintainers

👋

Sponsorship

If your company benefits from this library, please consider sponsoring its development.

For Enterprise

Tidelift Professional support for urllib3 is available as part of the Tidelift Subscription. Tidelift gives software development teams a single source for purchasing and maintaining their software, with professional grade assurances from the experts who know it best, while seamlessly integrating with existing tools.
Comments
  • http/socks4/socks5 Proxy support

    http/socks4/socks5 Proxy support

    I've finally managed to refactor the proxy support changes from requests lib into urllib3.

    Test results:

    
     foxx@test01 [~/development/urllib3] > python test/test_proxy.py
    TEST Proxy: http://192.168.56.1:8888
    HTTPS OK
    HTTP OK
    
    ---
    TEST Proxy: socks4://192.168.56.1:8889
    HTTPS OK
    HTTP OK
    
    ---
    TEST Proxy: socks5://192.168.56.1:8889
    HTTPS OK
    HTTP OK
    
    ---
    TEST: No proxy via PoolManager
    HTTPS OK
    HTTP OK
    
    ---
    TEST: No proxy via connection_from_url
    HTTPS OK
    HTTP OK
    

    Could one of the core devs please review this patch and make sure you are happy with it. Once signed off, I will go ahead and do a documentation update as well (want to make sure everyone's happy first).

    I've used as many of the suggestions from other tickets as possible, but please let me know if I have missed anything or if it needs to be changed.

    My sincere apologies it has taken so long to get this done, spare time is like gold dust :(

    This references the following discussions:

    https://github.com/shazow/urllib3/pull/56 https://github.com/kennethreitz/requests/pull/478 https://github.com/kennethreitz/requests/issues/362

    Others involved: @senko @wolever @kennethreitz @shazow @Anorov

    opened by foxx 119
  • Feature: Remove support for common names in certificates

    Feature: Remove support for common names in certificates

    We should follow the lead of Chromium. We should deprecate support for use of common names when a certificate doesn't provide a subjectAltName.

    This will bring us into compliance with the >10 year old RFC 2818

    Proposed Solution Accepted Breaking Change 
    opened by sigmavirus24 118
  • Create custom Selectors (Kqueue, Epoll, Poll, and Select) Backport

    Create custom Selectors (Kqueue, Epoll, Poll, and Select) Backport

    This PR adds all the select methods to a new util module called wait. Uses the same ordering used by selectors.py in the standard library to determine which selector should be used. Also factored in a way to allow easy patching and testing. Similar to #998 but uses a different way to break up the different methods to wait for I/O events. Also adds tests to exercise the selectors which can probably be extended.

    opened by sethmlarson 109
  • HTTPS proxy support (issue #50)

    HTTPS proxy support (issue #50)

    This Pull Request resolves #50 adding HTTPS (CONNECT) proxy support to ProxyManager with minimal API and code changes.

    A short summary of the changes:

    • ProxyManager is a subclass of PoolManager now and its logic has been changed completely, though its constructor still accepts HTTPConnectionPool as the main argument so it's backwards compatible
    • Tiny change to VerifiedHTTPSConnection.connect() that introduces CONNECT tunneling support (copied from HTTPConnection.connect() code)
    • HTTPSConnectionPool._new_conn() has been changed, but its logic for non-proxied connections stays the same
    • HTTPSConnectionPool._new_conn() actually establishes the connection for proxied requests by calling HTTPSConnection.connect(), otherwise Host: header is set improperly due to httplib logic. As stated above, the behavior for non-proxied requests hasn't changed
    • tornado-proxy has been added for tests
    • TornadoServerThread has been changed a bit - now it's possible to run multiple server threads in a single test case
    • Added proxy tests
    • Docs updated

    All tests run fine with Python 2.6, 2.7 and 3.2 on Mac OS 10.7.5, except for sporadic timeouts and SSL errors that occur against the unpatched library as well (and should be fixed separately). The code doesn't introduce any new regressions.

    Possible TODOs and improvements:

    • Proxy authentication (though that could be another libraries' responsibility, like requests)
    • When accepting proxy_pool as the first argument for ProxyManager, copy all pool properties and use them for other pool instances generation or even use it as the pool for HTTP proxy requests
    • Usage of HTTPConnectionPool and, especially, HTTPSConnectionPool against proxy isn't really clear and requires some external logic - much like ProxyManager.connection_from_host()
    opened by stanvit 72
  • RFC: what do you think of this branch adding async support to urllib3?

    RFC: what do you think of this branch adding async support to urllib3?

    We (mostly @pquentin and I) have been working on a proof of concept for adding pluggable async support to urllib3, with the hope of eventually getting this into the upstream urllib3. It's reached the point where there's still lots of missing bits, but there's an end-to-end demo working and we don't see any major obstacles to getting everything else working, so I wanted to start getting feedback from the urllib3 maintainers about whether this looks like something you'd be interested in eventually merging, and what it would take to get there.

    Demo

    So: hi! Check it out – a single py2.py3 wheel that keeps the classic synchronous API, and on python 3.6+ it can also run in async mode on both Trio and Twisted:

    # Demo from commit 1ca67ee53e18f823d0cb in the python-trio/urllib3 bleach-spike branch
    $ curl -O https://vorpus.org/~njs/tmp/async-urllib3-demo.zip
    $ unzip async-urllib3-demo.zip
    $ cd async-urllib3-demo
    $ ls
    sync-demo.py
    async-demo.py
    urllib3-2.0.dev0+bleach.spike.proof.of.concept.dont.use-py2.py3-none-any.whl
    
    $ virtualenv -p python3.6 py36-venv
    $ py36-venv/bin/pip install trio twisted[tls] urllib3-2.0.dev0+bleach.spike.proof.of.concept.dont.use-py2.py3-none-any.whl
    
    $ py36-venv/bin/python sync-demo.py
    --- urllib3 using synchronous sockets ---
    URL: http://httpbin.org/uuid
    Status: 200
    Data: b'{\n  "uuid": "a2c28245-47b8-4a50-b64c-da09d27bf626"\n}\n'
    
    $ py36-venv/bin/python async-demo.py
    --- urllib3 using Trio ---
    URL: http://httpbin.org/uuid
    Status: 200
    Data: b'{\n  "uuid": "dab50c1a-1b20-483f-903e-fe74494629f2"\n}\n'
    
    --- urllib3 using Twisted ---
    URL: http://httpbin.org/uuid
    Status: 200
    Data: b'{\n  "uuid": "72196b66-7caa-40dd-9c7c-af65bb4f7fb6"\n}\n'
    
    $ virtualenv -p python2 py2-venv
    $ py2-venv/bin/pip install urllib3-2.0.dev0+bleach.spike.proof.of.concept.dont.use-py2.py3-none-any.whl
    $ py2-venv/bin/python sync-demo.py
    --- urllib3 using synchronous sockets ---
    URL: http://httpbin.org/uuid
    Status: 200
    Data: '{\n  "uuid": "2a2fce90-d853-4940-b111-0969f92b7678"\n}\n'
    

    Things that (probably) don't work yet include: HTTPS, timeouts, proper connection reuse, using python 2 to run setup.py bdist_wheel, running the test suite. OTOH some non-trivial things do work, like chunked transfer encoding, and there's at least code in there for proxy support and handling early responses from the server.

    what sorcery is this

    This is based on @Lukasa's "v2" branch, so it's using h11. (Goodbye httplib :wave:.) The v2 branch is currently stalled in a pretty half-finished state (e.g. the I/O layer is a bunch of raw select loops open-coded everywhere that IIRC don't work; I'm sure @Lukasa would have cleaned it up if he had more time); we cleaned all that up and made it work. The major new code is here: https://github.com/python-trio/urllib3/blob/bleach-spike/urllib3/_async/connection.py

    And then we made the low-level I/O pluggable – there's a small-ish ad hoc API providing the set of I/O operations that urllib3 actually needs, and several implementations using different backends. Note that the I/O backend interface is internal, so we can adjust it as needed; there's no attempt to provide a generic abstract I/O interface that would work for anyone else. The code for the backends is here: https://github.com/python-trio/urllib3/tree/bleach-spike/urllib3/_backends

    Then we started adding async/await annotations to the rest of urllib3's code. That gave us a version that could work on Trio and Twisted. But wait, we also want to support python 2! And everyone using the existing synchronous API on python 3 too, for that matter. But we don't want to maintain two copies of the code. Unfortunately, Python absolutely insists that async APIs and synchronous APIs be loaded from different copies of the code; there's no way around this. (Mayyybe if we dropped python 2 support and were willing to maintain a giant shim layer then it would be possible, but I don't think either of those things is true.)

    Solution: we maintain one copy of the code – the version with async/await annotations – and then a little script maintains the synchronous copy by automatically stripping them out again. It's not beautiful, but as far as I can tell all the alternatives are worse.

    Currently the async version (source of truth) lives in urllib3/_async/, and then setup.py has the code to automatically generate urllib3/_sync/... at build time. (This script should probably get factored out into a separate project.) The script is not at all clever; you can see the exact set of transformations in the file, but basically it just tokenizes the source, deletes async and await tokens, and renames a few other tokens like __aenter____enter__. There's no complicated AST manipulation and comments are preserved. Then urllib3/__init__.py imports things from urllib3._sync and (if it's running on a new enough Python) urllib3._async.

    The resulting dev experience is sort of half-way between that of a pure-python project and one with a C extension: instead of an edit/run cycle, you need to do an edit/compile/run cycle. But you still end up with a nice py2.py3-none-any wheel at the end, so you don't need to stress out about providing binary builds for different platforms, and the builds are extremely fast because it's just some shallow text manipulation, not invoking a C compiler.

    Oh, and for backcompat we also added some shim files like urllib3/connectionpool.py, that just re-export stuff from the corresponding files in urllib3/_sync/..., since these submodules are documented as part of the API. This also has the benefit of making it easier to avoid accidentally exporting things in the future; urllib3's public API is perhaps larger than it should be.

    Importantly, this basic strategy would also work for libraries that use urllib3, so it provides a path forward for higher-level projects like requests, botocore, etc. to provide dual sync/async APIs while supporting python 2 + multiple async backends.

    Backwards compatibility

    So far this is looking surprisingly good. Switching to h11 means losing most of urllib3.connection, since that's directly exposing httplib APIs. In async mode we can't support lazily loading response.data, but that's fine, and we can still support it in sync mode if we want. Right now the branch is keeping the "close" operations synchronous, but we might want to switch to making them async, because it might make things easier for HTTP/2 later. If we do switch to async close, then that will force some broader changes – in particular RecentlyUsedContainer assumes that it can close things from __setitem__ and __delitem__, which can't be made async. It wouldn't be hard to rewrite RecentlyUsedContainer, but right now technically it's a public API.

    I'm not sure about some of the more obscure stuff like urllib3.contrib. In particular urllib3.contrib.pyopenssl, urllib3.contrib.socks, and urllib3.contrib.securetransport seem difficult to handle in a I/O-backend-agnostic way – maybe we could hack them to keep working on the sync backend only? And I don't know what to think about the appengine support. Maybe it's fine because it doesn't actually use urllib3 internals at all?

    But overall, my impression is that we could keep quite a high degree of backwards compatibility if we want. Perhaps we'd want to break things for other reasons if we're doing a v2, but that's a separate discussion.

    Questions

    Basically at this point it seems clear that this approach can work. And what's left is just straightforward work. So:

    • Does this seem like the direction we want urllib3 to go?

    • If so, then how would you like that process to go?

    I know @Lukasa is wary of the code generation approach, but the alternatives seem to be (a) maintaining a ton of redundant code, (b) not supporting async in urllib3, in which case the community will... end up maintaining a ton of redundant code as each I/O library separately implements their own fake copy of requests. And I don't believe that we have enough HTTP experts in the community to do that well; I think there are huge benefits to concentrating all our maintainers on a single library if we can.

    CC: @kennethreitz @markrwilliams

    opened by njsmith 62
  • Make a logo for urllib3

    Make a logo for urllib3

    @sethmlarson had a cute idea: ur//ib3, kinda inspired by Mozilla's moz://a.

    Would be fun to make stickers for future PyCons and whatnot.

    Maybe someone is inspired to take a shot at this?

    Or maybe we can convince a designer of one of the corporate sponsors to take a stab at it? :D

    Help Wanted Documentation 
    opened by shazow 58
  • [RFC] HPKP

    [RFC] HPKP

    HPKP is cool, and I think we should be able to do it.

    This issue tracks us (me?) spiking out how best to do it. I believe we can do it, and continue to be Python HTTP security wizards.

    People who may want to watch this issue: @sigmavirus24 @reaperhulk @dstufft @tiran.

    opened by Lukasa 56
  • [WIP] Remove httplib.

    [WIP] Remove httplib.

    This branch contains the most substantial chunk of work I have ever done on urllib3: the beginnings of an effort to remove our dependency on httplib.

    Removing our dependency on httplib has been a long-held desire of the urllib3 project. In fact, it's so desired that #776 (our wishlist of features for v2.0) includes in a section entitled "unlikely longshots" the phrase "Get rid of httplib dependence".

    This branch does exactly that, by bringing the http.client implementation from Python 3.5 that we were already used to interacting with into our codebase and then ripping its guts out and replacing them with @njsmith's h11 library.

    As you can see from the commit log, my work on this began back in October, but I've sat on it for the past two months in order to get it to a place where I had something worth showing. Now I finally do. On my machine, a run of tox -e py27 passes all tests, albeit with incomplete test coverage:

    py27 runtests: commands[1] | nosetests
    SSS....................S....................................................................................................................................S.....................................................S........................................................................................................................................................................................................................SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS...............................S..S..............................S................................................................................
    Name                      Stmts   Miss  Cover   Missing
    -------------------------------------------------------
    urllib3                      20      0   100%   
    urllib3._collections        148      0   100%   
    urllib3.connection          515    103    80%   80-82, 158, 162, 175, 229, 261, 285, 295-300, 306-338, 341-364, 368-372, 375, 385-392, 396-399, 408, 449, 453, 471, 567, 571-572, 602-611, 615, 651-652, 657, 729-732, 736-740, 755, 781, 830, 855-856, 868-869, 905-906, 972-973, 985, 1005
    urllib3.connectionpool      240      1    99%   256
    urllib3.contrib               0      0   100%   
    urllib3.contrib.socks        35      0   100%   
    urllib3.exceptions           73      2    97%   216, 219
    urllib3.fields               62      0   100%   
    urllib3.filepost             32      0   100%   
    urllib3.poolmanager         124      0   100%   
    urllib3.request              32      0   100%   
    urllib3.response            232      1    99%   453
    urllib3.util                  1      0   100%   
    urllib3.util.connection      47      0   100%   
    urllib3.util.request         37      0   100%   
    urllib3.util.response        19      5    74%   54-65
    urllib3.util.retry          121      0   100%   
    urllib3.util.selectors      295     45    85%   101, 360-423
    urllib3.util.ssl_            64      0   100%   
    urllib3.util.timeout         48      0   100%   
    urllib3.util.url             97      0   100%   
    urllib3.util.wait            14      1    93%   21
    -------------------------------------------------------
    TOTAL                      2256    158    93%   
    ----------------------------------------------------------------------
    Ran 604 tests in 13.646s
    
    OK (SKIP=42)
    ___________________________________ summary ____________________________________
      py27: commands succeeded
      congratulations :)
    

    Initially, my goal was to do this in the least-disruptive way possible: that's why I began by trying to replicate the logic of httplib inside urllib3 but on top of h11. I would have succeeded in that goal if I'd been able to avoid rewriting any tests in any substantive way.

    Unfortunately, as you can see from this change, I did not succeed at that. In particular, it was simply not possible to continue with some behaviours that urllib3 had previously promised, such as maintaining header case. I also had to bend over backwards to preserve some other behaviours urllib3 users have expected, such as reporting chunk boundaries, which is probably not something we should ever have promised to do.

    From my perspective, then, I think that if we want to continue this work it needs to be considered a breaking change for urllib3. Any change this substantial simply cannot be done in a non-breaking way. A huge number of things will change: our tolerance of errors (we're much stricter now because h11 is much more insistent about being spec-compliant), our wire format (h11 does some case normalization on header field names), and maybe even some of our output formats.

    This is also still very much a work in progress. There are TODO statements everywhere. The code is poorly factored: it's a wacky in-between state between trying to maintain the httplib abstraction and a total rejection of it in favour of something much clearer. A whole lot of our code that worked around httplib flaws is no longer necessary and can be removed, but hasn't yet been. A better underlying implementation that doesn't perform socket writes would also be possible, as would some refactoring of code I wrote to pull out common features. And the Python 3 tests don't pass, mostly because of the fact that right now this new branch emits headers as bytestrings rather than unicode strings.

    However, at this point it's no longer feasible for me to work on this branch alone. Further progress requires actual governance decisions, and I am not qualified to make those on my own, nor should I. urllib3 has a great collection of core maintainers and regular contributors whose opinions and work I value, and would like to solicit to help me. As I see it, we need to answer the following questions:

    1. Is this worth doing? Do we want to be rid of httplib so badly that we will perform a massive codebase rewrite to get rid of it?
    2. If so, are we happy with using h11?
      1. If we are, do we depend on it using pip, or vendor it? How does our decision affect Requests?
    3. Should this be the beginning of a v2.0 branch that will contain other bits of work from #776?
      1. If it should, how many breakages do we want to roll into one change? Do we want to go all in and leave a massive codebase change?
    4. What pieces of functionality do we want to retain from the old codebase? In particular, do we want:
      1. To still have stream() expose chunk boundaries?
      2. To return str header field names and values on Python 3?
      3. To return different types for header field names and values on Python 3?
      4. To implement buffered I/O in the low-level primitives?
      5. To maintain the weird two-level Response structure where we have a urllib3 Response object that contains a httplib Response object within it?
    5. How would we want to manage a rollout of this functionality?
    6. How do we want to review it?
    7. What kind of timeline do we want for releasing it?
    8. If we decide to go ahead with a v2.0, should we freeze the current master branch for everything except bug/security fixes until we complete v2.0?

    When @shazow originally made me interim lead maintainer, he told me that I had complete authority because he could always undo any change I made that he didn't like. I think this particular change is an exception: I don't think I have any degree of "lead maintainer" authority on this. We're going to need @shazow to express some opinions too.

    While I'm here, I'd also like to tag a few community members that are particularly likely to be interested in this proposal:

    /cc @njsmith @durin42 @dstufft

    opened by Lukasa 48
  • Use CaseInsensitiveMultiDict for headers

    Use CaseInsensitiveMultiDict for headers

    (Re: issue #236)

    First go at implementing this. Not 100% sure of the scope so there might be some features missing/extraneous items, would like to start discussion regardless.

    opened by jschneier 48
  • update of urllib3 makes kodi start up much slower

    update of urllib3 makes kodi start up much slower

    Is it normal that the update to version 1.25 makes kodi start up much slower? With version 1.22 it takes about 20 seconds to start up my rpi with kodi and all the add-ons. After the latest update of a couple of says ago to 1.25.1 and also with 1.25.2 which I installed from zip it takes about 45 seconds to start up with all the add-ons. Is this to be expected and if so will the slow down only in the startup or can it also be in the use of kodi and addons?

    Thank you

    opened by peno64 47
  • contrib.appengine.AppEngineManager

    contrib.appengine.AppEngineManager

    This is currently very rough and early. I want to make sure I'm on the right track before continuing.

    Outstanding questions:

    1. What functionality should be covered by the connection pool? (retries, etc.)
    2. Should I just inherit from TestConnectionPool and null out the tests that aren't applicable to GAE instead of duplicating code?
    3. How should this connection class be wired in? On GAE Sandbox environments w/o sockets, I assume this should be default.
    4. What exact edge cases should this class be aware; e.g, where does URLFetch behavior differ from what's expected of httplib/sockets? Do the tests already cover this?

    [_shazow edit: Fixes #664]_

    opened by theacodes 47
  • Bump ossf/scorecard-action from 2.1.1 to 2.1.2

    Bump ossf/scorecard-action from 2.1.1 to 2.1.2

    Bumps ossf/scorecard-action from 2.1.1 to 2.1.2.

    Release notes

    Sourced from ossf/scorecard-action's releases.

    v2.1.2

    What's Changed

    Fixes

    Full Changelog: https://github.com/ossf/scorecard-action/compare/v2.1.1...v2.1.2

    Commits
    • e38b190 Bump docker tag for release. (#1055)
    • 7da02bf Bump scorecard to v4.10.2 to remove a CODEOWNERS printf statement. (#1054)
    • 013c0f8 :seedling: Bump actions/dependency-review-action from 3.0.1 to 3.0.2
    • f93c094 :seedling: Bump github/codeql-action from 2.1.36 to 2.1.37
    • ce8978e :seedling: Bump actions/upload-artifact from 3.1.0 to 3.1.1
    • 5ce49db :seedling: Bump actions/setup-go from 3.4.0 to 3.5.0
    • See full diff in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies github_actions 
    opened by dependabot[bot] 0
  • Bump actions/setup-python from 4.3.1 to 4.4.0

    Bump actions/setup-python from 4.3.1 to 4.4.0

    Bumps actions/setup-python from 4.3.1 to 4.4.0.

    Release notes

    Sourced from actions/setup-python's releases.

    Add support to install multiple python versions

    In scope of this release we added support to install multiple python versions. For this you can try to use this snippet:

        - uses: actions/setup-python@v4
          with:
            python-version: |
                3.8
                3.9
                3.10
    

    Besides, we changed logic with throwing the error for GHES if cache is unavailable to warn (actions/setup-python#566).

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies github_actions 
    opened by dependabot[bot] 0
  • Retry cant handle float in retry-after header

    Retry cant handle float in retry-after header

    Subject

    When the Retry-After header contains a float, for example "0.503", then parse_retry_after raises an invalid header error.

    Environment

    OS Windows-10-10.0.19045-SP0 Python 3.10.3 urllib3 1.26.13

    Steps to Reproduce

    I cant really give an easy way to reproduce... the tedious way: generate python code with openapi-generator from this api https://github.com/SpaceTradersAPI/api-docs/tree/2.0.0-rc.2 hit any endpoint often enough to trigger the ratelimit which should be 2 requests/sec

    EDIT: pull my repo change the main() in api.py a bit to send enough requests and see the ratelimit apply https://github.com/feba66/spacetraders-sdk

    Expected Behavior

    parse the float correctly and wait the correct time before retrying

    Actual Behavior

    the regex match returns false because a dot is present and then tries to parse the date from "0.503" which fails

    possible fix

    change the regex to allow for a float and change the conversion from int(retry_after) to float(retry_after)

    opened by feba66 0
  • Send a clearer error message if response is truncated before a chunk

    Send a clearer error message if response is truncated before a chunk

    If a chunked response is truncated exactly before sending a new chunk (that is, before the first byte of the chunk size), urllib3 throws InvalidChunkLength(got length b'\\n', 0 bytes read). This is confusing as no chunk length was sent (a valid chunk length line would also be \r\n-terminated and we didn't see those either).

    If the chunk length is the empty string, send a different error message.

    opened by rnewson 0
Releases(2.0.0a2)
  • 2.0.0a2(Nov 23, 2022)

    Read the v2.0 migration guide for help upgrading to the latest version of urllib3.

    • Changed HTTPResponse.read() to raise an error when calling with decode_content=False after using decode_content=True to prevent data loss (https://github.com/urllib3/urllib3/issues/2800).
    • Changed HTTPResponse.getheaders() and .getheader() to previous behavior in 1.26.x. Instead we are deprecating these methods in favor of HTTPResponse.headers.items() and HTTPResponse.headers.get(). Both deprecated methods will be removed in v2.1.0 (https://github.com/urllib3/urllib3/issues/2814)
    • Fixed an issue where parsing a URL with leading zeroes in the port would be rejected even when the port number after removing the zeroes was valid. (https://github.com/urllib3/urllib3/pull/2806)
    • Fixed deprecation warning when using cryptography v39.0.0. This fix requires using pyOpenSSL>=17.1.0 and cryptography>=1.9. (https://github.com/urllib3/urllib3/pull/2829)
    Source code(tar.gz)
    Source code(zip)
    urllib3-2.0.0a2-py3-none-any.whl(120.22 KB)
    urllib3-2.0.0a2.tar.gz(268.37 KB)
    urllib3.intoto.jsonl(13.34 KB)
  • 1.26.13(Nov 23, 2022)

  • 2.0.0a1(Nov 15, 2022)

    Read the v2.0 migration guide for help upgrading to the latest version of urllib3!

    Added

    • Added type hints to the urllib3 module (#1897).
    • Added ssl_minimum_version and ssl_maximum_version options which set SSLContext.minimum_version and SSLContext.maximum_version (#2110).
    • Added support for Zstandard (RFC 8878) when zstandard 1.18.0 or later is installed. Added the zstd extra which installs the zstandard package (#1992).
    • Added urllib3.response.BaseHTTPResponse class. All future response classes will be subclasses of BaseHTTPResponse (#2083).
    • Added top-level urllib3.request function which uses a preconfigured module-global PoolManager instance (#2150).
    • Added FullPoolError which is raised when PoolManager(block=True) and a connection is returned to a full pool (#2197).
    • Added HTTPHeaderDict to the top-level urllib3 namespace (#2216).
    • Added the json parameter to urllib3.request(), PoolManager.request(), and ConnectionPool.request() methods to send JSON bodies in requests. Using this parameter will set the header Content-Type: application/json if Content-Type isn't already defined. Added support for parsing JSON response bodies with HTTPResponse.json() method (#2243).
    • Added support for configuring header merging behavior with HTTPHeaderDict When using a HTTPHeaderDict to provide headers for a request, by default duplicate header values will be repeated. But if combine=True is passed into a call to HTTPHeaderDict.add, then the added header value will be merged in with an existing value into a comma-separated list (X-My-Header: foo, bar) (#2242).
    • Added NameResolutionError exception when a DNS error occurs (#2305).
    • Added proxy_assert_hostname and proxy_assert_fingerprint kwargs to ProxyManager (#2409).
    • Added a configurable backoff_max parameter to the Retry class. If a custom backoff_max is provided to the Retry class, it will replace the Retry.DEFAULT_BACKOFF_MAX (#2494).
    • Added the authority property to the Url class as per RFC 3986 3.2. This property should be used in place of netloc for users who want to include the userinfo (auth) component of the URI (#2520).
    • Added the scheme parameter to HTTPConnection.set_tunnel to configure the scheme of the origin being tunnelled to (#1985).
    • Added the is_closed, is_connected and has_connected_to_proxy properties to HTTPConnection (#1985).

    Removed

    • Removed support for Python 2.7, 3.5, and 3.6 (#883, #2336).
    • Removed fallback on certificate commonName in match_hostname() function. This behavior was deprecated in May 2000 in RFC 2818. Instead only subjectAltName is used to verify the hostname by default. To enable verifying the hostname against commonName use SSLContext.hostname_checks_common_name = True (#2113).
    • Removed support for Python with an ssl module compiled with LibreSSL, CiscoSSL, wolfSSL, and all other OpenSSL alternatives. Python is moving to require OpenSSL with PEP 644 (#2168).
    • Removed support for OpenSSL versions earlier than 1.1.1 or that don't have SNI support. When an incompatible OpenSSL version is detected an ImportError is raised (#2168).
    • Removed the list of default ciphers for OpenSSL 1.1.1+ and SecureTransport as their own defaults are already secure (#2082).
    • Removed urllib3.contrib.appengine.AppEngineManager and support for Google App Engine Standard Environment (#2044).
    • Removed deprecated Retry options method_whitelist, DEFAULT_REDIRECT_HEADERS_BLACKLIST (#2086).
    • Removed urllib3.HTTPResponse.from_httplib (#2648).
    • Removed default value of None for the request_context parameter of urllib3.PoolManager.connection_from_pool_key. This change should have no effect on users as the default value of None was an invalid option and was never used (#1897).
    • Removed the urllib3.request module. urllib3.request.RequestMethods has been made a private API. This change was made to ensure that from urllib3 import request imported the top-level request() function instead of the urllib3.request module (#2269).
    • Removed support for SSLv3.0 from the urllib3.contrib.pyopenssl even when support is available from the compiled OpenSSL library (#2233).
    • Removed the deprecated urllib3.contrib.ntlmpool module (#2339).
    • Removed DEFAULT_CIPHERS, HAS_SNI, USE_DEFAULT_SSLCONTEXT_CIPHERS, from the private module urllib3.util.ssl_ (#2168).
    • Removed urllib3.exceptions.SNIMissingWarning (#2168).
    • Removed the _prepare_conn method from HTTPConnectionPool. Previously this was only used to call HTTPSConnection.set_cert() by HTTPSConnectionPool (#1985).
    • Removed tls_in_tls_required property from HTTPSConnection. This is now determined from the scheme parameter in HTTPConnection.set_tunnel() (#1985).

    Changed

    • Changed urllib3.response.HTTPResponse.read to respect the semantics of io.BufferedIOBase regardless of compression. Specifically, this method:
      • Only returns an empty bytes object to indicate EOF (that is, the response has been fully consumed).
      • Never returns more bytes than requested.
      • Can issue any number of system calls: zero, one or multiple. If you want each urllib3.response.HTTPResponse.read call to issue a single system call, you need to disable decompression by setting decode_content=False (#2128).
    • Changed ssl_version to instead set the corresponding SSLContext.minimum_version and SSLContext.maximum_version values. Regardless of ssl_version passed SSLContext objects are now constructed using ssl.PROTOCOL_TLS_CLIENT (#2110).
    • Changed default SSLContext.minimum_version to be TLSVersion.TLSv1_2 in line with Python 3.10 (#2373).
    • Changed ProxyError to wrap any connection error (timeout, TLS, DNS) that occurs when connecting to the proxy (#2482).
    • Changed urllib3.util.create_urllib3_context to not override the system cipher suites with a default value. The new default will be cipher suites configured by the operating system (#2168).
    • Changed multipart/form-data header parameter formatting matches the WHATWG HTML Standard as of 2021-06-10. Control characters in filenames are no longer percent encoded (#2257).
    • Changed urllib3.HTTPConnection.getresponse to return an instance of urllib3.HTTPResponse instead of http.client.HTTPResponse (#2648).
    • Changed return type of HTTPResponse.getheaders() method to return a list of key-value tuples to match CPython (#1543).
    • Changed the error raised when connecting via HTTPS when the ssl module isn't available from SSLError to ImportError (#2589).
    • Changed HTTPConnection.request() to always use lowercase chunk boundaries when sending requests with Transfer-Encoding: chunked (#2515).
    • Changed enforce_content_length default to True, preventing silent data loss when reading streamed responses (#2514).
    • Changed internal implementation of HTTPHeaderDict to use dict instead of collections.OrderedDict for better performance (#2080).
    • Changed the urllib3.contrib.pyopenssl module to wrap OpenSSL.SSL.Error with ssl.SSLError in PyOpenSSLContext.load_cert_chain (#2628).
    • Changed usage of the deprecated socket.error to OSError (#2120).
    • Changed all parameters in the HTTPConnection and HTTPSConnection constructors to be keyword-only except host and port (#1985).
    • Changed urllib3.util.is_connection_dropped() to use HTTPConnection.is_connected (#1985).
    • Changed HTTPConnection.getresponse() to set the socket timeout from HTTPConnection.timeout value before reading data from the socket. This previously was done manually by the HTTPConnectionPool calling HTTPConnection.sock.settimeout(...) (#1985).
    • Changed the _proxy_host property to _tunnel_host in HTTPConnectionPool to more closely match how the property is used (value in HTTPConnection.set_tunnel()) (#1985).
    • Changed name of Retry.BACK0FF_MAX to be Retry.DEFAULT_BACKOFF_MAX.
    • Changed TLS handshakes to use SSLContext.check_hostname when possible (#2452).
    • Changed server_hostname to behave like other parameters only used by HTTPSConnectionPool (#2537).
    • Changed the default blocksize to 16KB to match OpenSSL's default read amounts (#2348).

    Deprecated

    • Deprecated urllib3.contrib.pyopenssl module which will be removed in urllib3 v2.1.0 (#2691).
    • Deprecated urllib3.contrib.securetransport module which will be removed in urllib3 v2.1.0 (#2692).
    • Deprecated ssl_version option in favor of ssl_minimum_version. ssl_version will be removed in urllib3 v2.1.0 (#2110).
    • Deprecated the strict parameter as it's not longer needed in Python 3.x. It will be removed in urllib3 v2.1.0 (#2267)
    • Deprecated the NewConnectionError.pool attribute which will be removed in urllib3 v2.1.0 (#2271).
    • Deprecated format_header_param_html5 and format_header_param in favor of format_multipart_header_param (#2257).
    • Deprecated RequestField.header_formatter parameter which will be removed in urllib3 v2.1.0 (#2257).
    • Deprecated HTTPSConnection.set_cert() method. Instead pass parameters to the HTTPSConnection constructor (#1985).
    • Deprecated HTTPConnection.request_chunked() method which will be removed in urllib3 v2.1.0. Instead pass chunked=True to HTTPConnection.request() (#1985).

    Fixed

    • Fixed thread-safety issue where accessing a PoolManager with many distinct origins would cause connection pools to be closed while requests are in progress (#1252).
    • Fixed an issue where an HTTPConnection instance would erroneously reuse the socket read timeout value from reading the previous response instead of a newly configured connect timeout. Instead now if HTTPConnection.timeout is updated before sending the next request the new timeout value will be used (#2645).
    • Fixed socket.error.errno when raised from pyOpenSSL's OpenSSL.SSL.SysCallError (#2118).
    • Fixed the default value of HTTPSConnection.socket_options to match HTTPConnection (#2213).
    • Fixed a bug where headers would be modified by the remove_headers_on_redirect feature (#2272).
    • Fixed a reference cycle bug in urllib3.util.connection.create_connection() (#2277).
    • Fixed a socket leak if HTTPConnection.connect() fails (#2571).
    Source code(tar.gz)
    Source code(zip)
    urllib3-2.0.0a1-py3-none-any.whl(120.56 KB)
    urllib3-2.0.0a1.tar.gz(268.72 KB)
    urllib3.intoto.jsonl(13.45 KB)
  • 1.26.12(Aug 22, 2022)

  • 1.26.11(Jul 25, 2022)

    If you or your organization rely on urllib3 consider supporting us via GitHub Sponsors.

    :warning: urllib3 v2.0 will drop support for Python 2: Read more in the v2.0 Roadmap

    • Fixed an issue where reading more than 2 GiB in a call to HTTPResponse.read would raise an OverflowError on Python 3.9 and earlier.
    Source code(tar.gz)
    Source code(zip)
    urllib3-1.26.11-py2.py3-none-any.whl(136.62 KB)
    urllib3-1.26.11-py2.py3-none-any.whl.crt(1.31 KB)
    urllib3-1.26.11-py2.py3-none-any.whl.sig(141 bytes)
    urllib3-1.26.11.tar.gz(292.24 KB)
    urllib3-1.26.11.tar.gz.crt(1.31 KB)
    urllib3-1.26.11.tar.gz.sig(141 bytes)
  • 1.26.10(Jul 7, 2022)

    If you or your organization rely on urllib3 consider supporting us via GitHub Sponsors.

    :warning: urllib3 v2.0 will drop support for Python 2: Read more in the v2.0 Roadmap

    :closed_lock_with_key: This is the first release to be signed with Sigstore! You can verify the distributables using the .sig and .crt files included on this release.

    • Removed support for Python 3.5
    • Fixed an issue where a ProxyError recommending configuring the proxy as HTTP instead of HTTPS could appear even when an HTTPS proxy wasn't configured.
    Source code(tar.gz)
    Source code(zip)
    urllib3-1.26.10-py2.py3-none-any.whl(135.92 KB)
    urllib3-1.26.10-py2.py3-none-any.whl.crt(1.31 KB)
    urllib3-1.26.10-py2.py3-none-any.whl.sig(137 bytes)
    urllib3-1.26.10.tar.gz(290.87 KB)
    urllib3-1.26.10.tar.gz.crt(1.31 KB)
    urllib3-1.26.10.tar.gz.sig(137 bytes)
  • 1.26.9(Mar 16, 2022)

    If you or your organization rely on urllib3 consider supporting us via GitHub Sponsors.

    :warning: urllib3 v2.0 will drop support for Python 2: Read more in the v2.0 Roadmap

    :warning: This release will be the last release supporting Python 3.5. Please upgrade to a non-EOL Python version.

    • Changed urllib3[brotli] extra to favor installing Brotli libraries that are still receiving updates like brotli and brotlicffi instead of brotlipy. This change does not impact behavior of urllib3, only which dependencies are installed.
    • Fixed a socket leaking when HTTPSConnection.connect() raises an exception.
    • Fixed server_hostname being forwarded from PoolManager to HTTPConnectionPool when requesting an HTTP URL. Should only be forwarded when requesting an HTTPS URL.
    Source code(tar.gz)
    Source code(zip)
    urllib3-1.26.9-py2.py3-none-any.whl(135.73 KB)
    urllib3-1.26.9.tar.gz(288.33 KB)
  • 1.26.8(Jan 7, 2022)

    If you or your organization rely on urllib3 consider supporting us via GitHub Sponsors.

    :warning: urllib3 v2.0 will drop support for Python 2: Read more in the v2.0 Roadmap

    :warning: This release will be the last release supporting Python 3.5. Please upgrade to a non-EOL Python version.

    • Added extra message tourllib3.exceptions.ProxyError when urllib3 detects that a proxy is configured to use HTTPS but the proxy itself appears to only use HTTP.
    • Added a mention of the size of the connection pool when discarding a connection due to the pool being full.
    • Added explicit support for Python 3.11.
    • Deprecated the Retry.MAX_BACKOFF class property in favor of Retry.DEFAULT_MAX_BACKOFF to better match the rest of the default parameter names. Retry.MAX_BACKOFF is removed in v2.0.
    • Changed location of the vendored ssl.match_hostname function from urllib3.packages.ssl_match_hostname to urllib3.util.ssl_match_hostname to ensure Python 3.10+ compatibility after being repackaged by downstream distributors.
    • Fixed absolute imports, all imports are now relative.
    Source code(tar.gz)
    Source code(zip)
    urllib3-1.26.8-py2.py3-none-any.whl(135.44 KB)
    urllib3-1.26.8.tar.gz(287.38 KB)
  • 1.26.7(Sep 22, 2021)

  • 1.26.6(Jun 25, 2021)

    :warning: IMPORTANT: urllib3 v2.0 will drop support for Python 2: Read more in the v2.0 Roadmap

    • Deprecated the urllib3.contrib.ntlmpool module. urllib3 is not able to support it properly due to reasons listed in this issue. If you are a user of this module please leave a comment.
    • Changed HTTPConnection.request_chunked() to not erroneously emit multiple Transfer-Encoding headers in the case that one is already specified.
    • Fixed typo in deprecation message to recommend Retry.DEFAULT_ALLOWED_METHODS.

    If you or your organization rely on urllib3 consider supporting us via GitHub Sponsors

    Source code(tar.gz)
    Source code(zip)
    urllib3-1.26.6-py2.py3-none-any.whl(135.24 KB)
    urllib3-1.26.6.tar.gz(283.13 KB)
  • 1.26.5(May 26, 2021)

  • 1.26.4(Mar 15, 2021)

  • 1.26.3(Jan 26, 2021)

    :warning: IMPORTANT: urllib3 v2.0 will drop support for Python 2: Read more in the v2.0 Roadmap

    • Fixed bytes and string comparison issue with headers (Pull #2141)

    • Changed ProxySchemeUnknown error message to be more actionable if the user supplies a proxy URL without a scheme (Pull #2107)

    If you or your organization rely on urllib3 consider supporting us via GitHub Sponsors

    Source code(tar.gz)
    Source code(zip)
  • 1.26.2(Nov 12, 2020)

  • 1.26.1(Nov 11, 2020)

  • 1.26.0(Nov 10, 2020)

    :warning: IMPORTANT: urllib3 v2.0 will drop support for Python 2: Read more in the v2.0 Roadmap

    • Added support for HTTPS proxies contacting HTTPS servers (Pull #1923, Pull #1806)

    • Deprecated negotiating TLSv1 and TLSv1.1 by default. Users that still wish to use TLS earlier than 1.2 without a deprecation warning should opt-in explicitly by setting ssl_version=ssl.PROTOCOL_TLSv1_1 (Pull #2002) Starting in urllib3 v2.0: Connections that receive a DeprecationWarning will fail

    • Deprecated Retry options Retry.DEFAULT_METHOD_WHITELIST, Retry.DEFAULT_REDIRECT_HEADERS_BLACKLIST and Retry(method_whitelist=...) in favor of Retry.DEFAULT_ALLOWED_METHODS, Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT, and Retry(allowed_methods=...) (Pull #2000) Starting in urllib3 v2.0: Deprecated options will be removed

    • Added default User-Agent header to every request (Pull #1750)

    • Added urllib3.util.SKIP_HEADER for skipping User-Agent, Accept-Encoding, and Host headers from being automatically emitted with requests (Pull #2018)

    • Collapse transfer-encoding: chunked request data and framing into the same socket.send() call (Pull #1906)

    • Send http/1.1 ALPN identifier with every TLS handshake by default (Pull #1894)

    • Properly terminate SecureTransport connections when CA verification fails (Pull #1977)

    • Don't emit an SNIMissingWarning when passing server_hostname=None to SecureTransport (Pull #1903)

    • Disabled requesting TLSv1.2 session tickets as they weren't being used by urllib3 (Pull #1970)

    • Suppress BrokenPipeError when writing request body after the server has closed the socket (Pull #1524)

    • Wrap ssl.SSLError that can be raised from reading a socket (e.g. "bad MAC") into an urllib3.exceptions.SSLError (Pull #1939)

    Source code(tar.gz)
    Source code(zip)
  • 1.25.11(Oct 19, 2020)

    • Fix retry backoff time parsed from Retry-After header when given in the HTTP date format. The HTTP date was parsed as the local timezone rather than accounting for the timezone in the HTTP date (typically UTC) (#1932, #1935, #1938, #1949)

    • Fix issue where an error would be raised when the SSLKEYLOGFILE environment variable was set to the empty string. Now SSLContext.keylog_file is not set in this situation (#2016)

    Source code(tar.gz)
    Source code(zip)
  • 1.25.10(Jul 22, 2020)

  • 1.25.8(Jan 21, 2020)

  • 1.25.6(Sep 24, 2019)

  • 1.25.5(Sep 20, 2019)

  • 1.25.4(Sep 19, 2019)

  • 1.24.3(May 2, 2019)

  • 1.25.1(Apr 24, 2019)

  • 1.25(Apr 22, 2019)

As easy as /aitch-tee-tee-pie/ 🥧 Modern, user-friendly command-line HTTP client for the API era. JSON support, colors, sessions, downloads, plugins & more. https://twitter.com/httpie

HTTPie: human-friendly CLI HTTP client for the API era HTTPie (pronounced aitch-tee-tee-pie) is a command-line HTTP client. Its goal is to make CLI in

HTTPie 25.4k Jan 1, 2023
Some example code for using a raspberry pi to draw text (including emojis) and twitch emotes to a HUB75 RGB matrix via an HTTP post endpoint.

Some example code for using a raspberry pi to draw text (including emojis) and twitch emotes to a HUB75 RGB matrix via an HTTP post endpoint.

null 7 Nov 5, 2022
Small, fast HTTP client library for Python. Features persistent connections, cache, and Google App Engine support. Originally written by Joe Gregorio, now supported by community.

Introduction httplib2 is a comprehensive HTTP client library, httplib2.py supports many features left out of other HTTP libraries. HTTP and HTTPS HTTP

null 457 Dec 10, 2022
Screaming-fast Python 3.5+ HTTP toolkit integrated with pipelining HTTP server based on uvloop and picohttpparser.

Screaming-fast Python 3.5+ HTTP toolkit integrated with pipelining HTTP server based on uvloop and picohttpparser.

Paweł Piotr Przeradowski 8.6k Jan 4, 2023
An interactive command-line HTTP and API testing client built on top of HTTPie featuring autocomplete, syntax highlighting, and more. https://twitter.com/httpie

HTTP Prompt HTTP Prompt is an interactive command-line HTTP client featuring autocomplete and syntax highlighting, built on HTTPie and prompt_toolkit.

HTTPie 8.6k Dec 31, 2022
EasyRequests is a minimalistic HTTP-Request Library that wraps aiohttp and asyncio in a small package that allows for sequential, parallel or even single requests

EasyRequests EasyRequests is a minimalistic HTTP-Request Library that wraps aiohttp and asyncio in a small package that allows for sequential, paralle

Avi 1 Jan 27, 2022
A simple, yet elegant HTTP library.

Requests Requests is a simple, yet elegant HTTP library. >>> import requests >>> r = requests.get('https://api.github.com/user', auth=('user', 'pass')

Python Software Foundation 48.8k Jan 5, 2023
Asynchronous HTTP client/server framework for asyncio and Python

Async http client/server framework Key Features Supports both client and server side of HTTP protocol. Supports both client and server Web-Sockets out

aio-libs 13.1k Jan 1, 2023
🔄 🌐 Handle thousands of HTTP requests, disk writes, and other I/O-bound tasks simultaneously with Python's quintessential async libraries.

?? ?? Handle thousands of HTTP requests, disk writes, and other I/O-bound tasks simultaneously with Python's quintessential async libraries.

Hackers and Slackers 15 Dec 12, 2022
A Python obfuscator using HTTP Requests and Hastebin.

?? Jawbreaker ?? Jawbreaker is a Python obfuscator written in Python3, using double encoding in base16, base32, base64, HTTP requests and a Hastebin-l

Billy 50 Sep 28, 2022
Probe and discover HTTP pathname using brute-force methodology and filtered by specific word or 2 words at once

pathprober Probe and discover HTTP pathname using brute-force methodology and filtered by specific word or 2 words at once. Purpose Brute-forcing webs

NFA 41 Jul 6, 2022
A next generation HTTP client for Python. 🦋

HTTPX - A next-generation HTTP client for Python. HTTPX is a fully featured HTTP client for Python 3, which provides sync and async APIs, and support

Encode 9.8k Jan 5, 2023
Python requests like API built on top of Twisted's HTTP client.

treq: High-level Twisted HTTP Client API treq is an HTTP library inspired by requests but written on top of Twisted's Agents. It provides a simple, hi

Twisted Matrix Labs 553 Dec 18, 2022
Asynchronous Python HTTP Requests for Humans using Futures

Asynchronous Python HTTP Requests for Humans Small add-on for the python requests http library. Makes use of python 3.2's concurrent.futures or the ba

Ross McFarland 2k Dec 30, 2022
HTTP/2 for Python.

Hyper: HTTP/2 Client for Python This project is no longer maintained! Please use an alternative, such as HTTPX or others. We will not publish further

Hyper 1k Dec 23, 2022
HTTP request/response parser for python in C

http-parser HTTP request/response parser for Python compatible with Python 2.x (>=2.7), Python 3 and Pypy. If possible a C parser based on http-parser

Benoit Chesneau 334 Dec 24, 2022
Aiosonic - lightweight Python asyncio http client

aiosonic - lightweight Python asyncio http client Very fast, lightweight Python asyncio http client Here is some documentation. There is a performance

Johanderson Mogollon 93 Jan 6, 2023
Python package for caching HTTP response based on etag

Etag cache implementation for HTTP requests, to save request bandwidth for a non-modified response. Returns high-speed accessed dictionary data as cache.

Rakesh R 2 Apr 27, 2022
A minimal HTTP client. ⚙️

HTTP Core Do one thing, and do it well. The HTTP Core package provides a minimal low-level HTTP client, which does one thing only. Sending HTTP reques

Encode 306 Dec 27, 2022