在Firefox中意外Signalr连接中止 [英] Unexpected Signalr connection abort in Firefox

查看:368
本文介绍了在Firefox中意外Signalr连接中止的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我使用SignalR(跨域请求),用于网上聊天集成ASP.NET网站版本2.3.0。一切工作正常。但我发现SignalR连接的奇怪的行为。当我点击从聊天标签的参考文件下载SignalR连接被中止,onDisconnected方法在我的HUB类被触发。萤火告诉我下一个POST请求:

I am using SignalR (with cross-domain request), version 2.3.0 for webchat integrated to ASP.NET site. Everything is working fine. But I found strange behaviour of SignalR connection. When I clicked to the reference from tab of the chat for file downloading SignalR connection was aborted and onDisconnected method was triggered in my Hub class. FireBug show me next POST-request:

http://*:81/signalr/abort?transport=longPolling&clientProtocol=1.4&token=eUpLNitKcmR1d2JhTTRvcHNVZmEwcG1EKzYvMElZbmg4aE5yam9xM3k0dz0_IjAsNGJmOWNhODUtNDU2NS00NWExLWFjMTgtNzgyN2FhZDA2Njg1LGxvY2FsaG9zdCI1&State=1&connectionToken=hDXe9xIZtmrapjl1LRwtK9B%2BfYMoeuHka8ctBLaPa0YnjiN9iiFa%2BvFMBHIGpGH0h8qPEDgGZSRGwjMw3Wm1DJi6cUPtZjLca6%2FR2576SGksLAj3lnPN1JWIlxMsn8%2Bf&connectionData=%5B%7B%22name%22%3A%22c%22%7D%2C%7B%22name%22%3A%22voip%22%7D%5D,其中*是我的域名。

http://*:81/signalr/abort?transport=longPolling&clientProtocol=1.4&token=eUpLNitKcmR1d2JhTTRvcHNVZmEwcG1EKzYvMElZbmg4aE5yam9xM3k0dz0_IjAsNGJmOWNhODUtNDU2NS00NWExLWFjMTgtNzgyN2FhZDA2Njg1LGxvY2FsaG9zdCI1&State=1&connectionToken=hDXe9xIZtmrapjl1LRwtK9B%2BfYMoeuHka8ctBLaPa0YnjiN9iiFa%2BvFMBHIGpGH0h8qPEDgGZSRGwjMw3Wm1DJi6cUPtZjLca6%2FR2576SGksLAj3lnPN1JWIlxMsn8%2Bf&connectionData=%5B%7B%22name%22%3A%22c%22%7D%2C%7B%22name%22%3A%22voip%22%7D%5D, where * is my domain.

这是在Mozilla Firefox再现(30.0版本)LongPolling或WebSocket的传输。我怎样才能解决这个问题?或者是SignalR或Firefox的错误?

It is reproduced in Mozilla Firefox (version 30.0) for LongPolling or Websocket transports. How I can fix this problem? Or is it bug of SignalR or Firefox?

推荐答案

此错误最近已起诉SignalR在GitHub上。其基本思路是,下载文件导致Firefox触发 window.onbeforeunload 事件从而导致SignalR关闭任何正在进行的连接。

This bug has been recently filed against SignalR on GitHub. The basic idea is that downloading a file causes Firefox to trigger the window.onbeforeunload event which in turn causes SignalR to close any ongoing connections.

目前,解决办法是附加一个句柄到客户端断开事件,将调用 $。connection.start 后再次短暂窗口.setTimeout

For now, the workaround is to attach a handler to the client's disconnected event that will call $.connection.start again after a short window.setTimeout.

您也可以解除SignalR的onbeforeunload处理程序: $(窗口).unbind(beforeunload)。这样做的缺点是,当用户离开该页面运行SignalR火狐可能无法正常断开连接。如果没有优美的脱节,SignalR将等待30秒钟,然后超时的客户端,并呼吁集线器的 OnDisconnected 处理程序 PersistentConnection

You could also unbind SignalR's onbeforeunload handler: $(window).unbind("beforeunload"). The downside of doing this is that Firefox might not gracefully disconnect when the user leaves the page running SignalR. Without a graceful disconnect, SignalR will wait over 30 seconds before it times out the client and calls the OnDisconnected handler on the Hub or PersistentConnection.

这篇关于在Firefox中意外Signalr连接中止的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆