On Windows 2003 64bit, Apache is mostly installed in the "Program Files (x86)" folder, and the parentheses cause the trouble here, as mod_ssl tries to read the cache size out of them. I suggest either changing the ( ) to < >, as those are not allowed in folder names in Windows, or search the string right to left, getting the correct pair of parentheses containing the size. SSLSessionCache "shmcb:C:/Program Files (x86)/Apache2.2/logs/ssl_scache(512000)" ^ fails. Thanks
In trunk/2.4 you can simply omit the part after the "shmcb:" and the code will DTRT. Not sure what else we could do here.
Created attachment 24064 [details] Path to resolve (x86) path issue. Potential patch to resolve the issue with 64bit windows and folders that contain the '(' character. The patch check to see if the last character is a ')' and will then search for a '(' starting at the right of the string.
The same error has occured for me on 64-bit Windows 7 (RTM), using Apache/2.2.13. Presumably this occurs on all 64-bit versions of Windows. A good solution for this would be to comply with Windows conventions and install data in "\ProgramData" instead of "\Program Files" or "\Program Files (x86)". Things like logs, configuration files, etc really should be installed there. Doing so would also avoid the problem of (x86) creeping into the folder name and triggering this bug. Generally, you would want to setup data and logs in the Windows Known Folder '%ALLUSERSPROFILE%' or '%ProgramData%'. More information available at http://msdn.microsoft.com/en-us/library/bb756896.aspx and http://msdn.microsoft.com/en-us/library/bb762584%28VS.85%29.aspx
**Workaround** The shmcb method doesn't actually create a file on the filesystem, so you can use an arbitrary pathname. Just make sure it's unique on the system. Examples: SSLSessionCache "shmcb:C:\apache\port80\instance1(512000)" and SSLSessionCache "shmcb:C:\apache\port443\instance2(512000)"
(In reply to comment #4) > **Workaround** > > The shmcb method doesn't actually create a file on the filesystem, so you can > use an arbitrary pathname. Just make sure it's unique on the system. FYI: That's only on windows. I don't think you can work around a path name with () in them on unix. :-(
*** This bug has been marked as a duplicate of bug 47945 ***