On Tue, Sep 18, 2012 at 11:39 PM, James Peach <jpe...@apache.org> wrote: > On 18/09/2012, at 1:52 PM, Jan-Frode Myklebust <janfr...@tanso.net> wrote: > >> On Tue, Sep 18, 2012 at 3:02 PM, Igor Galić <i.ga...@brainsware.org> wrote: >>> >>> Yeh. We'll need to back-port the fix to not ALWAYS assume SNI for >>> all SSL connections, since not quite all browsers support that yet >>> >>> @James, can you please do the proposal, kthnxby >>> >>>> -jf >> >> This is already in the CHANGES/PATCHES ACCEPTED TO BACKPORT FROM TRUNK >> list in v3.2.x, and what we're already using (sorry for referring to >> wrong commit earlier): >> >> *) Fix SNI certificate fallback path >> Trunk: 9c3bebd88eecf6aee1ce346b67460b8e1787752d >> Jira: https://issues.apache.jira/browse/TS-1471 >> +1: jpeach, igalic, zwoop >> >> But when applying 8586b8ec6d6e934233fc195a4f35944cea1d85a4 on top of >> it it looks like non-SNI browsers broke again... > > Ok, 9c3bebd88eecf6aee1ce346b67460b8e1787752d is the right fix for this; it > supersedes 8586b8ec6d6e934233fc195a4f35944cea1d85a4. >
Then I'm back to where I started... 3.2.0 + 9c3bebd88eecf6aee1ce346b67460b8e1787752d fixes ssl for non-SNI browsers, but gives me the stack trace in http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201209.mbox/%3c72718d13-bf27-410f-bbc5-cb306e2fddcd@iris%3e every now and then.. -jf
