evercookie – virtually irrevocable persistent cookies

evercookie is a javascript API available that produces extremely persistent cookies in a browser. Its goal is to identify a client even after they’ve removed standard cookies, Flash cookies (Local Shared Objects or LSOs), and others. evercookie accomplishes this by storing the cookie data in several types of storage mechanisms that are available on the local browser. Additionally, if evercookie has found the user has removed any of the types of cookies in question, it recreates them using each mechanism available.


maccman’s juggernaut at master – GitHub

Juggernaut lets you push data to browser, which means you can do awesome things like multiplayer gaming, chat, realtime collaboration and more! Juggernaut is super simple and easy to get going.
* node.js server
* Ruby client
* Supports the following protocols:
* WebSocket
* Adobe Flash Socket
* ActiveX HTMLFile (IE)
* Server-Sent Events (Opera)
* XHR with multipart encoding
* XHR with long-polling
* Reconnection support


WebTest Key Characteristics

WebTest has an easy syntax with steps having meaningful names that can be understood even when you don’t know WebTest. Additionally, the recorder allows you to quickly generate a first draft of your tests that you can adapt and refactor to build robust tests suites. Don’t forget: capture/replay is the least cost-effective way of automating test cases!


kanaka’s noVNC at master – GitHub

noVNC is a VNC client implemented using HTML5 technologies, specifically Canvas and WebSocket (supports ‘wss://’ encryption).
For browsers that do not have builtin WebSocket support, the project includes web-socket-js, a WebSocket emulator using Adobe Flash .
In addition, as3crypto has been added to web-socket-js to implement WebSocket SSL/TLS encryption, i.e. the “wss://” URI scheme.


EricLaw’s IEInternals : COMET Streaming in Internet Explorer

One challenge with using XMLHTTPRequest is that browsers behave differently when it comes to streaming of content. A common complaint against XMLHTTPRequest in IE was that it doesn’t stream content. More specifically, the responseText property cannot be queried when readyState=3 (Receiving) and it only becomes available when readyState=4 (Loaded). This means that while your JavaScript will know when the transfer of the response body starts, you must wait for the response to complete before examining it. If your goal is to stream down a “never-ending” stream of data, you’ll find that IE’s XHR object never gets to the Loaded readyState and thus you cannot examine the “partial” response.

Load More