Just had this problem occur again last night.  With gzip encoding turned
off, it seems much better (20 days this time instead of 6 hours!), but alas,
it did produce the error until I restarted the webserver.

I will upgrade to the new release and restart tonight.  Time will tell if
any of the included fixes may correct this error, too.

Ryan


On Mon, Apr 12, 2010 at 8:40 AM, Ryan McIntosh <[email protected]>wrote:

> 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.com and 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

Reply via email to