3 ms·

I say hurrah! There is an awful little dance you can do to make SNI work in 2.7 with requests but it is way too complicated for most deployments: https://githu

I say hurrah! There is an awful little dance you can do to make SNI work in 2.7 with requests but it is way too complicated for most deployments: https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/contrib/pyopenssl.py https://github.com/kennethreitz/requests/blob/master/request... I've actually done this once. Took all day.

kordless 12y ago
I spent a whole day just trying to figure out what was wrong with my code on the site. Worked fine in dev, but when pushed to AppEngine, it just flat out broke my API calls. FWIW, if you want to get a virtual IP on AppEngine (which fixes the 'problem'), it's like $40-something a month extra.
- mmastrac 12y ago
  That's what we ended up doing. It's expensive per month, but you can roll up multiple sites under a wildcard cert (I think -- I'd have to ask the devops guy who is thankfully dealing with this mess).
  - harshreality 12y ago
    Yes. The criteria for avoiding SNI is one IP per cert, not necessarily one IP per domain. If you can consolidate subdomains under one cert, you only need one IP. The issue that SNI deals with is with cert switching on a single ip:port... not anything inherently related to multiple domains on an IP.
Lukasa 12y ago
Yeah, we're not delighted about how complicated this is, but it's really the best we could do. =( To be clear though, Requests only requires the three packages be installed, it'll do everything else automatically. Actually, is there interest in this being an installable add-on? Meaning you'd run: pip install requests[SNI] to get it?
- jccooper 12y ago
  I'm just glad it exists at all. Saved my bacon wrt backend toolchain when I set up SSL through App Engine. I think my problems were with getting pyOpenSSL compiled for Windows and/or my way-too-old Ubuntu. Or maybe it was pycrypto as a deeper dependency. Something like that. I'm sure an add-on would be nice, though I'm not sure it would solve what I ran into. But with Python 2.7.7 coming up pretty soon, may not be worth the effort.

kordless 12y ago

I spent a whole day just trying to figure out what was wrong with my code on the site. Worked fine in dev, but when pushed to AppEngine, it just flat out broke my API calls. FWIW, if you want to get a virtual IP on AppEngine (which fixes the 'problem'), it's like $40-something a month extra.

mmastrac 12y ago
That's what we ended up doing. It's expensive per month, but you can roll up multiple sites under a wildcard cert (I think -- I'd have to ask the devops guy who is thankfully dealing with this mess).
- harshreality 12y ago
  Yes. The criteria for avoiding SNI is one IP per cert, not necessarily one IP per domain. If you can consolidate subdomains under one cert, you only need one IP. The issue that SNI deals with is with cert switching on a single ip:port... not anything inherently related to multiple domains on an IP.

Lukasa 12y ago

Yeah, we're not delighted about how complicated this is, but it's really the best we could do. =( To be clear though, Requests only requires the three packages be installed, it'll do everything else automatically. Actually, is there interest in this being an installable add-on? Meaning you'd run: pip install requests[SNI] to get it?

jccooper 12y ago
I'm just glad it exists at all. Saved my bacon wrt backend toolchain when I set up SSL through App Engine. I think my problems were with getting pyOpenSSL compiled for Windows and/or my way-too-old Ubuntu. Or maybe it was pycrypto as a deeper dependency. Something like that. I'm sure an add-on would be nice, though I'm not sure it would solve what I ran into. But with Python 2.7.7 coming up pretty soon, may not be worth the effort.