I haven't encountered the problem in nearly a week after turning off gzip encoding. Any thoughts on why this might be a factor?
Ryan On Wed, Apr 7, 2010 at 8:20 AM, Ryan McIntosh <[email protected]> wrote: > Yes - same firefox 3.6 browser, two tabs - one is > https://www.bestbridalprices.com, one is > https://staging.bestbridalprices.com > > www would be producing the error while staging would be fine. > > I woke up at 4am this morning in a cold sweat with that revelation in my > head. > > Ryan > > > On Wed, Apr 7, 2010 at 7:48 AM, Alvaro Lopez Ortega > <[email protected]>wrote: > >> Hi Ryan, >> >> That is REALLY interesting. Could you please check whether the problem >> shows up if you access different virtual servers from the same browser? >> >> On 07/04/2010, at 14:31, Ryan McIntosh wrote: >> >> > Since I turned off gzip encoding in the config this problem hasn't >> reared it's head yet. I'll let it run like this for another couple of days >> for a longer term test, but this seems promising. >> > >> > I realized something last night though that I am slapping myself for not >> flagging earlier. This configuration uses virtual hosts. The >> SSL_BAD_SIGNATURE error only occurs on one virtual host when it happens. >> It's not always the same one. Sometimes it's admin.bestbridalprices.comand >> sometimes it's >> www.bestbridalprices.com I've never seen it on any other virtual host. >> The configuration is not using a wildcard ssl certificate - the non www >> virtual hosts are for internal use only. >> > >> > Since some virtual hosts work fine when the problem is occuring on >> another, it leads me to believe that whatever error is occuring AFTER the >> SSL handshake and at least before the http-host header is sent - possibly >> after. The problem is arising during the HTTP portion of the communication. >> Definately a significant clue. It is no wonder openssl s_client wasn't >> producing any meaningful errors but for the one time. It makes me wonder if >> the error I did see the once was unrelated. >> > >> > Ryan >> > >> > On Tue, Apr 6, 2010 at 12:05 PM, Ryan McIntosh <[email protected]> >> wrote: >> > You're correct. Adding the DH Parameter files did not resolve anything. >> I just had to restart the server again. >> > >> > Anything else I can try? >> > >> > Alvaro, you mention bad content-length and/or bad content-encoding. >> I'll try disabling gzip. >> > >> > When cherokee calculates content-length, does it consider encodings, or >> does it just count bytes? I'm not familiar enough with HTTP to know if >> that's a dumb question or not. >> > >> > Ryan >> > >> > >> > On Tue, Apr 6, 2010 at 9:46 AM, Alvaro Lopez Ortega < >> [email protected]> wrote: >> > On 06/04/2010, at 15:53, Ryan McIntosh wrote: >> > >> > > Even with an hourly restart, this error is still occuring >> sporadically. Once further piece of information I didn't realize may be >> significant before is that I have not configured DH parameters. I'm not >> sure if they're at all necessary as SSL was still working and I've never had >> to do this with any other webserver. Are the DH parameters are used for >> generating the session keys? Perhaps creating DH parameter files will do >> something for me? >> > >> > The DH parameters file does not have anything to do with the problem, >> I'm quite sure about that. >> > >> > I still believe that the problem is somehow related to keep-alive, >> unfinished connections, bad content-lenght and/or bad content-encoding. >> > >> > > I will test and write back. >> > >> > Thanks for all the finding and reports! >> > >> > -- >> > Octality >> > http://www.octality.com/ >> > >> > >> > >> >> -- >> Octality >> http://www.octality.com/ >> >> >
_______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
