Hacker News Reader

Comment by jccooper | Hacker News Reader

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/request...

I've actually done this once. Took all day.

View on HN

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?

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.

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.

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).

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.

Reply on news.ycombinator.com