Expose WebSocket HTTP Status code
Reported by
sha...@peer5.com,
Feb 24 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. Create a new WS connection 2. Close the WS connection from the server with a specific status code 3. The status code is not accessible from JS code, only from the network pane in the DevTools What is the expected behavior? There should be a property on the WebSocket object with the HTTP status received by the server. What went wrong? There is no property that represents the HTTP status code. Did this work before? N/A Does this work in other browsers? No Chrome version: 56.0.2924.87 Channel: stable OS Version: OS X 10.12.3 Flash Version: Shockwave Flash 24.0 r0 This is important as it can be used to differentiate between real disconnections, authentication issues, rate-limiting, etc.
,
Feb 24 2017
,
Feb 25 2017
This should be discussed at WHATWG than here to change the spec first. In my opinion, what we might be able to expose is aligned with what CORS allows. To expose the result for cross-origin resources, we need to do the same as CORS for the Fetch API and XHR. Please also see the warning in https://html.spec.whatwg.org/multipage/comms.html for the algorithm for "When the WebSocket connection is closed, possibly cleanly". We should be careful not to expose unnecessary information that can be abused for attack. |
|||
►
Sign in to add a comment |
|||
Comment 1 by ligim...@chromium.org
, Feb 24 2017