http://bugs.winehq.org/show_bug.cgi?id=16831
--- Comment #16 from TJ support@tjworld.net 2009-01-07 17:07:29 --- Success using patch 186561 "wininet: Secure flag has precedence over scheme."
Trace fragment shows:
trace:wininet:HTTP_Connect --> trace:wininet:WININET_AddRef 0x26fa1f8 -> refcount = 3 trace:wininet:WININET_AddRef 0x2424240 -> refcount = 2 trace:wininet:WININET_Release object 0x2424240 refcount = 1 trace:wininet:HTTP_Connect 0x26fa1f8 --> 0x2 (0x2424240) trace:wininet:HttpOpenRequestW (0x2, (null), L"/cgi-bin/licensemgr.cgi?action="..., (null), (null), 0x32c674, 80800002, 00000000) trace:wininet:HttpOpenRequestW accept type: L"*/*" trace:wininet:WININET_AddRef 0x2424240 -> refcount = 2 trace:wininet:WININET_GetObject handle 2 -> 0x2424240 trace:wininet:HTTP_HttpOpenRequestW --> trace:wininet:WININET_AddRef 0x2424240 -> refcount = 3 trace:wininet:WININET_AddRef 0x29aa4d0 -> refcount = 2 trace:wininet:NETCON_init using SSL connection
The problem I see with it is that because the URL_COMPONENTSW structure urlComponents.lpszScheme isn't in sync with urlComponents.nScheme or lpszUrl, subsequent code that might be dependent on the strings may behave unexpectedly. It would be most likely where a new URLCOMPONENTSW is built based on the original lpszUrl. This in addition to the "https://host.domain:80/" scenario.