Need user-facing warning in the browser if websocket connection fails #952

Closed
fperez opened this Issue Oct 30, 2011 · 4 comments

Comments

Projects
None yet
2 participants
@fperez
Member

fperez commented Oct 30, 2011

See #934 for more background. Right now if the websocket connection fails for any reason, the users are left with a mysteriously non-working notebook that appears to otherwise be ok, so it's quite hard to debug. We should propagate the error to the browser.

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Oct 31, 2011

Member

Sorry, I missed the sub-issue note in #934. GitHub has been finicky about auto-closing issues recently, so I saw that the title was fully addressed and confirmed as fixed, and thought it was another one of those.

For reference: The websocket version-check error code is #426. I'm not sure what the errors are in the host-mismatch error case.

Member

minrk commented Oct 31, 2011

Sorry, I missed the sub-issue note in #934. GitHub has been finicky about auto-closing issues recently, so I saw that the title was fully addressed and confirmed as fixed, and thought it was another one of those.

For reference: The websocket version-check error code is #426. I'm not sure what the errors are in the host-mismatch error case.

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Oct 31, 2011

Member

I've got a local version working that throws an alert (only tested in Chrome so far). The thing to catch is websocket.onclose, and check event.wasClean. For some reason, the actual responsecode doesn't seem to be available, but this does seem to catch both cases of the 426 error, and the bug preventing websocket urls from matching the http one.

@ellisonbg - is there a reason that the hostname/port of the websocket connection should not just match that of the http connection?

Member

minrk commented Oct 31, 2011

I've got a local version working that throws an alert (only tested in Chrome so far). The thing to catch is websocket.onclose, and check event.wasClean. For some reason, the actual responsecode doesn't seem to be available, but this does seem to catch both cases of the 426 error, and the bug preventing websocket urls from matching the http one.

@ellisonbg - is there a reason that the hostname/port of the websocket connection should not just match that of the http connection?

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Nov 11, 2011

Member

@minrk, now that #955 has been merged, should we close this one? Or do you have anything else in mind for it?

Member

fperez commented Nov 11, 2011

@minrk, now that #955 has been merged, should we close this one? Or do you have anything else in mind for it?

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Nov 11, 2011

Member

Yes, #955 was meant to cover this. Closing.

Member

minrk commented Nov 11, 2011

Yes, #955 was meant to cover this. Closing.

@minrk minrk closed this Nov 11, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment