Hi all,

I'd like to request an alternate resolution to the following issue:

    https://bugs.webkit.org/show_bug.cgi?id=41419 We should log the reason when 
a secure wss WebSocket connection could not be established
        (was: Secure wss WebSocket connections cannot be established)

Consider an example https://applicance.example.com, which uses a self-signed 
SSL certificate.  iOS Safari will warn the user:

          Cannot Verify Server Identify

          Safari can't verify the identity of "appliance.example.com".
          Would you like to continue anyway?

          Cancel / Details   /   Continue
The user chooses to "Continue".  Safari then trusts the identity of 
"appliance.example.com", and proceeds.  The resulting HTML may spawn additional 
https:// requests, which will also proceed.

Suppose though that a wss:// connection to "appliance.example.com" is 
initiated.  As issue 41419 states, this will fail in Safari and WebKit (r87480.)

Chrome on the other hand, consider the user's acceptance of the server's 
identity as valid for both wss:// and https:// connection.  This seems 
reasonable.  The user accepted the server's identity, with no caveat on the 
protocol.

Can this behaviour be implemented in WebKit as the resolution to issue 41419?


-Paul
[email protected]<mailto:[email protected]>


_______________________________________________
webkit-help mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-help

Reply via email to