News for hackers. Stuff that matters.
Re:Nginx sucks at SSL, here's what to do instead by stock_toaster on Monday July 11, 2011 @03:51PM (#2752220)
The post didn't mention if ssl_session_cache was enabled in the nginx config or not. In fact, I didn't see any configs posted. :(

Also, the article author apparently added support to stud (in his own fork) for x-forward-for. I don't think this is required any longer, due to this fairly recent stud commit: https://github.com/bumptech/stud/commit/9d9b52b7d3ce90fa84c6...

Re:Nginx sucks at SSL, here's what to do instead by seiji on Monday July 11, 2011 @06:12PM (#2752699)
I hear the same performance happens with our without the session cache enabled (for benchmarks). The http(s) benchmarking tools don't resume sessions. It's simulating a horde of new clients who never come back or request other resources.

It would be interesting to see stud with a session cache too.

Re:Nginx sucks at SSL, here's what to do instead by jamwt on Monday July 11, 2011 @04:20PM (#2752337)
I'm reading over Matt's work carefully, but my initial inclination is not to merge the bulk of this into stud mainline. I'd rather keep stud simple and protocol-naive and have HAProxy do the HTTP work.
Re:Nginx sucks at SSL, here's what to do instead by jamwt on Monday July 11, 2011 @04:36PM (#2752414)
Which is to say indirectly that I think the right answer is for nginx (and daemons generally) to support the PROXY protocol, or some other agreed-upon standard for a naive upstream proxy to indicate host/port information.
Re:Nginx sucks at SSL, here's what to do instead by sciurus on Monday July 11, 2011 @10:30PM (#2753299)
Could someone link to a description of the PROXY protocol?
Re:Nginx sucks at SSL, here's what to do instead by stock_toaster on Tuesday July 19, 2011 @10:40PM (#2784081)
Re:Nginx sucks at SSL, here's what to do instead by stock_toaster on Monday July 11, 2011 @07:15PM (#2752871)
I really agree with this. I think keeping stud as simple as possible is a great goal.
Re:Nginx sucks at SSL, here's what to do instead by seiji on Monday July 11, 2011 @06:41PM (#2752791)
I'm reading over Matt's work carefully

Thanks for the consideration!

initial inclination is not to merge the bulk of this into stud mainline

I agree. The HTTP stuff is still too integrated. ifdefs are ugly.

The solution is to do what showed up when I was 99% done working on XFF -- the nice PROXY protocol addition. We just need to get PROXY support into nginx now to obviate my XFF machinations.