is it possible to create and use a websocket in a web worker ?
I got this error :
WebSocket is not defined
Ps : I'm using the last version of Firefox.
Thank you
This is supported in Chrome (and I suspect also in IE 10 although I have tested).
There is a Firefox bug to implement the ability to use WebSockets in Web Workers: https://bugzilla.mozilla.org/show_bug.cgi?id=504553 I expect that it will be implemented in firefox within the next few months.
FWIW FireFox 38 : I'm able to use Websockets in Webworkers.
A January 1, 2015 comment suggests that WebSockets created in Web Workers won't be added to FireFox until version 37. Here the bug is shown as fixed for version 37.
Related
I've been investigating the implementation of CTAP2 protocol with Google Chrome (protocol between Fido Authenticator and Fido Client (e.g. Chrome)), which should be supported in Chrome since version 69.
So I dumped the chrome request to the authenticator in two cases:
1. U2F (CTAP1) with yubico demo website.
Here everything goes as expected and chrome follows the CTAP1 protocol.
2. FIDO2/Webauthn (CTAP2) with webauthn.org
And the browser has a strange behaviour:
It starts by following the CTAP2 protocol by sending a AuthenticatorGetInfoRequest
The Authenticator replies with AuthenticatorGetInfoResponse
But then Chrome switches to the CTAP1 protocol by sending a Registration Request Message (U2F_REGISTER)
Is it a problem with Chrome implementation: CTAP2 is not enabled entirely yet (it seems to be implemented in Chromium sources)?
Or is the problem coming from the authenticator: sending a response that makes Chrome switch to CTAP1?
Or something else entirely?
In AuthenticatorGetInfoRequest, the authenticator must respond with a string list of the supported versions among "U2F_V2" and "FIDO_2_0". Note also in case of NFC or CCID, a "FIDO_2_0" (CTAP2) only authenticator shall anwser directly "FIDO_2_0" on the SELECT command. I don't know about HID and BLE.
So maybe your authenticator is listing "U2F_V2" in the protocol versions list in AuthenticatorGetInfoRequest.
I also imagine the Chrome code base about this was moving fast and can be partial or not strict. To my tests in early 2020, the Chrome CTAP capabilities seem now stable and compliant.
I am working on webrtc chat app.
system1 : peer1, peer3 | system2 : peer2, peer4
What I did ?
For video call, I am creating one peer1, peer2, and that peer1 very successfully communicate with peer2 (consider video call only).
What I want to do?
I want, peer3 can communicate with new peer4(meanwhile I don't want to disconnect peer1-->peer2).
What happening ?
When I am creating peer3, on that time " navigator.mediaDevices.getUserMedia " getting errors !!!! (I am not using SSL) and new peer3 can't create !.
So, please tell me your suggestions regarding above problem.
It is possible to only peer1 can communicate with other any peer(bidirectional communication)??
This could be the browser failing to capture video from the webcam if it's already in use by another browser or another tab in the same browser. For example, Firefox 57 on my Ubuntu 16.04 machine exhibits this behavior (Chrome does not).
I am using Netty websockets and everything seems to work fine except this minor issue :
If I close the browser / tab of the js websocket client , the websocket connection is automatcally closed when using Mozilla firefox (currently using firefox 14) but the same thing does not happen in Chrome 20/21.
Anyone seen a similar issue / can anyone tell why is the connection not closed automatically ?
I guess I should have checked this earlier in the chromium bug section but I was not sure if it is a bug.
It has been reported earlier by someone and a chromium bug already exists :
Issue 51687 : WebSocket: Send close with code 1001 on reload / tab close
Update : Someone has submitted a patch to fix this issue, can be seen in the above link.
This may not be right, but I cannot post a comment to your question. Chrome/Chromium does not really close if you have an App running and have selected "Continue running background apps when Chromium is closed" from Settings-->Under the hood.
It may be that it treats the websocket connection as an app. Try looking at your running processes and kill any chrome/chromium process you find.
Again, this is just speculation on my part.
Chrome doesn't close the connection, when a user will close the window or browser.
It will trigger an Error event.
A possible workaround could look like this:
#OnError
public void onErr(Throwable t) {
onClose(this.container.getWsSession(), null);
}
But this will close the connection every time, an Error is triggered. You may wan't to check the throwable, before closing the connection by yourself.
For more discussion, please join this question:
Websocket: Closing browser triggers onError() in chrome but onClose() event in Firefox
i've already a working proxy.pac file. I'd like the clients to use different proxyserver depending on their web browser.
No problem I thought. There are many java script snippets out there, to detect browser name/version.
The samples I found uses all "navigator.appName". That works fine if I test this on a regular website. When I put the same into my proxy.pac, it doesn't work. The navigator object doesnt seem to exist.
Has anyone out there a suggestion how to switch the proxy according to the user agent?
My goal is, that all IE6 uses a specific proxy, where the rest just use the default proxy.
Background: IE6 does not support Kerberos authentication, which is used on the default proxy. Therefore I setup an additional proxy with LDAP authtentication.
Thanks in advance for any help.
Maybe there are some less or more subtle javascript engine differences between the browsers that one can spot, using for example
if (typeof(someIESpecificFunction) != "undefined")
or using try and catch
or comparing results of some builtin functions for subtle differences
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(ECMAScript) and http://www.robertnyman.com/javascript/index.html may be helpful for a start?
Update: one more browser-version specific behaviour:
from http://technet.microsoft.com/en-us/library/dd361918.aspx:
function FindProxyForURL(url, host)
{
if(weekdayRange("WED", "SAT", "GMT"))
return "PROXY proxy:80";
else
return "DIRECT";
}
The weekdayRange( <day1> [,<day2>] [,<GMT>] ) function returns whether the current system time falls within the range specified by the parameters <day1>, <day2>, and <GMT>. Only the first parameter is necessary. The GMT parameter sets the times to be taken in GMT rather than in the local time zone.
Note Where the function is called with <day1> == <day2>, previous versions of Internet Explorer would yield results different from results with Netscape Navigator. Specifically, previous versions of Internet Explorer would interpret this day range as an entire week, while Internet Explorer 6 and Netscape Navigator interpret the range as a single day. For example, if the current day is Monday, the call weekdayRange("TUE", "TUE") returns TRUE on previous versions of Internet Explorer and FALSE on Internet Explorer 6 and Netscape Navigator.
Update 2: According to http://blogs.msdn.com/b/wndp/archive/2006/07/18/ipv6-wpad-for-winhttp-and-wininet.aspx one should be able to distinguish also IE7 from older IE versions (other browsers may and may not support these extensions, like for example mentioned here about Chrome: http://code.google.com/p/pactester/issues/detail?id=9)
Based on the information so far it should be possible to distinguish IE 5.5, IE 6, IE 7, IE 8, IE 9?
Please let us know if You find anything like that useful.
You may try detecting IE inside PAC script via Conditional Compilation: const ifIE = /*#cc_on!#*/false;.
Conditional Compilation may vary depending on new or old IE/Edge versions.
I haven't done any testing of this answer --, please, let us know if it works in comments.
I came across this code change in Chromium. It says Chromium now supports both handshake versions, which the code seems to confirm. I mean the second version at Wikipedia (draft-ietf-hybi-thewebsocketprotocol-06).
However, when I connect to my server, the only thing I obtain is the old version, i.e. including these headers:
Sec-WebSocket-Key1: 4 #1 46546xW%0l 1 5
Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
but not the new version which would be a request containing:
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
What am I missing here? I downloaded the latest nightly build and it has been included more than two weeks ago, so that cannot be the cause I guess.
How can I make a WebSocket send the new handshake version?
The code link you posted is for the server-side of the handshake (there is a few places this will likely be used in Chrome such as remote debugging and as a proxy for extensions).
If you really want use the new HyBi-07 protocol version you can try using this branch of web-socket-js that I made. Once Chrome switch to the new protocol, web-socket-js will switch by default also. In order to make web-socket-js work in a browser that already has WebSockets support you will need make some minor tweaks to it to use a different object name instead of WebSocket.
I expect Chrome/WebKit will add the new protocol before long. Note that the API changes to add binary support have only recent been decided so Chrome the new protocol may be added before the API fully supports the new functionality enabled by the protocol.
The only browser I know of that implements the 07 protocol is this build of FF4:
http://www.ducksong.com/misc/websockets-builds/ws-07/