The author and maintainers of the popular Requests library are working on a crucial version 2.0 release. As you can see this new release will include a large number of bug fixes and features which are backwards incompatible with the 1.x branch of Requests. Not to worry though, the transition from 1.x to 2.x will be far less painful than the transition from 0.x to 1.x. Most of the backwards incompatibility arises from how 2.x will handle headers (as will be explained below).
Improving HTTPS proxy support
Perhaps the most exciting part of this upcoming release is the improved proxy support. Version 2 will include support for the
CONNECT verb which will make talking to HTTPS services possible from behind a proxy. For example: anyone who wishes to use Requests on PythonAnywhere‘s free tier will be able to once version 2 is released. As noted in the pull request, this would not be possible without the amazing work of the contributors to urllib3 — the library on top of which Requests is implemented.
Fixing a subtle bug with headers
Beyond adding proxies, there was a particularly nasty bug on Python 3 where some headers could not be set using native strings. As this was a backwards incompatible change this is only being fixed for the first time in version 2.0. If you have run into this problem your headaches will be long gone.
Adding new convenience methods
Finally, if you are a Requests user who creates their requests carefully by hand, the new method on the
Session object will prepare them for you! You no longer have to jump through extra hoops to include the cookies stored on the
Future Requests updates
As soon as Requests 2.0 is out, we will have a full review here, so be sure to subscribe to our Python tag and The Changelog Weekly for further updates.
Ever find yourself needing to
- Temporarily share a website that is only running on your dev machine?
- Demo an app at a hackathon without deploying?
- Develop any services which consume webhooks (HTTP callbacks)?
- Debug and understand a web service by inspecting the HTTP traffic?
- Run networked services on machines that are firewalled off from the internet?
All of these use cases and more are served by ngrok, a reverse proxy written in Go that creates a secure tunnel between a public endpoint and a locally running web service. Need a visual?
You download ngrok as a dependency-free binary, unzip it, and drop it in your
$PATH. Then you’re up and running in a single command. For instance:
The app shows you the URL to share and the web server to connect to for analysis:
It has a free server component that doesn’t require signing up, but there are additional features if you have an account.
The entire code base is open source under the Apache license and available on GitHub.
Switch branches as fast as you switch pages. Waiting for a deploy sucks. Allocating a staging server for each remote branch is costly. But nothing beats testing on a staging server with real production data. Divergence allows you to quickly test your remote branches simply by changing the subdomain.
If you’ve ever had the need for a second staging server for an early release of a feature that’s not ready to merge to master, Divergence from LayerVault could be what you’ve been waiting for.
With Divergence you can easily view any branch from your repository on your staging server by using the branch name as the subdomain. Just use your branch name as the sub-domain and Divergence will magically find your branch and serve it up. You can even hook into a number of callbacks to automatically restart Passenger, run
bundle install, or any other task if needed.
It’s a Rack application that acts as a HTTP proxy between you and your web application for rapid testing. Divergence was built with an Apache-Passenger stack in mind, so if you’re wanting to help develop the project further, checkout the contributing section of the readme.
Divergence is a work in progress, and labeled as a beta release. The folks at LayerVault could use a hand with:
- Increased language support
- More stacks supported, (e.g. nginx, Unicorn, etc.)
- HTTPS support built-in
Divergence::Application.configure do |config|
config.git_path = "/path/to/git_root"
config.app_path = "/path/to/app_root"
config.cache_path = "/path/to/cache_root"
config.forward_host = 'localhost'
config.forward_port = 80
config.callbacks :after_swap do
config.callbacks :after_cache, :after_webhook do
bundle_install :path => "vendor/bundle"
config.callbacks :on_branch_discover do |subdomain|
Checkout the repo and readme for detailed instructions on installation and setup. If you’d like to see more stacks supported beyond an Apache-Passenger stack, fork it and help out.