ricea
commented
1 year ago Yes, I think you're right.
Main fetch step 7 sets response to a network error, then step 29 runs "fetch response handover". Then at step 4 of fetch response handover we queue a task to run "process response" which takes us back to the WebSocket standard's establish a WebSocket connection step 11, which then calls "fail the WebSocket connection", which loops through RFC6455 and ends up back at "When the WebSocket connection is closed" which fires "error" and "close" events.
I don't really want to add a redundant mixed content check to the WebSocket standard, so I'm leaning towards aligning Blink's behaviour with the standard as written, ie. firing error and close events. I could add a console log to make up for the loss of diagnostic information.
@zcorpan Do you have opinions?
https://github.com/web-platform-tests/wpt/pull/40632 looks incorrect to me. The equivalent of a network error should happen, which doesn't end up yielding an exception, but rather an error event.