SNI support

[raphaelm]

In my setup the HTTP transport always failed because of an untrusted certificate. The certificate, however, was trusted, but the server sent the wrong certificate as raven's very own SSL wrapper apparently does not support TLS Server Name Indication. My guess is that this could be fixed by adding a server_hostname attribute with useful content to the ssl.wrap_socket call in raven.utils.http.urlopen.ValidHTTPSConnection.

[xordoquy]

Does this work with the request transport ?

[gavinwahl]

It does work with the requests transport, but then you lose the asynchronous thread feature.

[dcramer]

I would like to see:

1. How much work it is to support SNI / http proxy by ourselves
2. How much work it is to vendor requests
3. How much work it is to vendor urllib3 (which afaik provides all of the functionality that we want out of requests)

On Monday, December 1, 2014 at 4:48 PM, Gavin Wahl wrote:

It does work with the requests transport, but then you lose the asynchronous thread feature.

—
Reply to this email directly or view it on GitHub (#523 (comment)).

[xordoquy]

TBH, I'd go with vendoring requests. I don't have time to investigate on urllib3 or DYI SNI / proxy support in particular with how hard supporting some proxy is with the stdlibs

[fengsi]

+1 for this

[pypetey]

+1 for this

[serathius]

+1

[miracle2k]

I thought this was kind of nightmare, having to write code for 10+ apps after switching to LetsEncrypt on the server; but then I noticed there is a pretty easy way to change the transport via the url. Just use threaded+requests+https as a url scheme!

[gartens]

This fixed the problem for me. Should I submit a PR?

[fzarifian]

@gartens Something went wrong on your tests (see flake8 core tests)