{"action":"created","issue":{"url":"https://api.github.com/repos/square/okhttp/issues/1702","labels_url":"https://api.github.com/repos/square/okhttp/issues/1702/labels{/name}","comments_url":"https://api.github.com/repos/square/okhttp/issues/1702/comments","events_url":"https://api.github.com/repos/square/okhttp/issues/1702/events","html_url":"https://github.com/square/okhttp/pull/1702","id":88484602,"number":1702,"title":"Expose WebSocket.closeConnection() to public API","user":{"login":"pwerry","id":858772,"avatar_url":"https://avatars.githubusercontent.com/u/858772?v=3","gravatar_id":"","url":"https://api.github.com/users/pwerry","html_url":"https://github.com/pwerry","followers_url":"https://api.github.com/users/pwerry/followers","following_url":"https://api.github.com/users/pwerry/following{/other_user}","gists_url":"https://api.github.com/users/pwerry/gists{/gist_id}","starred_url":"https://api.github.com/users/pwerry/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pwerry/subscriptions","organizations_url":"https://api.github.com/users/pwerry/orgs","repos_url":"https://api.github.com/users/pwerry/repos","events_url":"https://api.github.com/users/pwerry/events{/privacy}","received_events_url":"https://api.github.com/users/pwerry/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-06-15T17:03:37Z","updated_at":"2015-06-16T11:29:57Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/square/okhttp/pulls/1702","html_url":"https://github.com/square/okhttp/pull/1702","diff_url":"https://github.com/square/okhttp/pull/1702.diff","patch_url":"https://github.com/square/okhttp/pull/1702.patch"},"body":"The reason for doing this is to expose an API to the client that allows it to force the connection to close. The current `WebSocket.close()` method (correctly) attempts to send a `WebSocket` close frame before shutting down the backing `Connection`. But if the `Connection` is in an SSL timeout state (for example, when Android is connected to a WiFi router dropping a ton of WAN packets), then this function will hang and there will be no way to force the `WebSocket` to terminate. Giving the client the power to force a `Connection` shutdown allows it to set up connect and shutdown timers coupled with reachability and make the right decisions."},"comment":{"url":"https://api.github.com/repos/square/okhttp/issues/comments/112391359","html_url":"https://github.com/square/okhttp/pull/1702#issuecomment-112391359","issue_url":"https://api.github.com/repos/square/okhttp/issues/1702","id":112391359,"user":{"login":"pwerry","id":858772,"avatar_url":"https://avatars.githubusercontent.com/u/858772?v=3","gravatar_id":"","url":"https://api.github.com/users/pwerry","html_url":"https://github.com/pwerry","followers_url":"https://api.github.com/users/pwerry/followers","following_url":"https://api.github.com/users/pwerry/following{/other_user}","gists_url":"https://api.github.com/users/pwerry/gists{/gist_id}","starred_url":"https://api.github.com/users/pwerry/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pwerry/subscriptions","organizations_url":"https://api.github.com/users/pwerry/orgs","repos_url":"https://api.github.com/users/pwerry/repos","events_url":"https://api.github.com/users/pwerry/events{/privacy}","received_events_url":"https://api.github.com/users/pwerry/received_events","type":"User","site_admin":false},"created_at":"2015-06-16T11:29:57Z","updated_at":"2015-06-16T11:29:57Z","body":"Jake exposing a `Timeout` would certainly solve the majority of cases, and would improve safety, so that's something I'd support. How would you expect that API to look? We could expose a configuration through the `WebSocketCall#create` API, but that would mean the `Timeout` wouldn't be call-time configurable. Clients will have a better understanding of the behaviour they require at the moment of shutdown than at configuration time. A timeout used locally during the `close()` process might be more appropriate."}}