LV WebSockets Release Notes.txt

LV WebSockets Release Notes

v1.8.0
- Improved error handling in client handshake
- Implemented URI parsing for wss/https URIs
- Implemented support for Secure WebSocket
- Now if the client/server handshaking fails the TCP connection will be closed
- Up to now, the Sec-WebSocket-Key was a value hard-coded in the code. Implemented the generation of a random 16 bytes string and then its encoding to a 24 bytes Base64 string as specified in the RFC 6455 . This will improve the security of the implementation
- Minor improvement to the example code
- The previous implementation of the Base64 encoding was relatively slow and inefficient. We have replaced it with a highly optimized pure LabVIEW implementations available here https://forums.ni.com/t5/Example-Code/Fast-Base64-Encoder-Decoder-using-LabVIEW/ta-p/3503281.
- As per RFC 2616 (referred in RFC 6455) headers should be matched in a case insensitive manner. This is was not done and caused a problem with certain WebSocket servers. We have implemented a case insensitive header matching.
v1.7.0
- Forked form v1.6.0.22 of the WebSockets package by MediaMongrels Ltd
- Since the fork the following changes have been implemented
	* Fixed a bugs in client handshake code:
		1. the client needs to send an HTTP full URI and not a WS URI when we decide to put a full URI and not just the a path in the request.
		2. The regex in the "Parse URI.vi" method has been improved for the dummy resource name "/"
	* Refactored  the client/server handshake code
	* added support for WebSockets resources names as per RFC 6455
	* Now the server handshake checks if a resource name is available as of the input array of resource names and it answers with a 404 Not Found HTTP response according to the RFC 6455. The answer is handled by the client handshake code which throws an error. Server handshake similarly handles the malformed client handshake by answering with a 400 Bad Request HTTP response according to RFC 6455. The response is handled by the client code throwing an error. We added a "ProcessHandshakeResponse.vi" that fully check the server response as of RFC 6455, before there was only a partial check obtained by reusing "the ProcessHandshakeRequest.vi"server code.
	* Data Framing Refactoring: Introduced a generic "SendDataFrame.vi" which sends a data frame according to all the possible Opcodes as defined "Opcodes.ctl" enum and also allows to set the Final Frame Bit (FIN Bit). This vi is now used in both the "Write.vi" and "Close.vi", as well as the newly introduced "Ping.vi" and "Pong.vi". 
	* The "Close.vi" now correctly sets the FIN bit and allows to send a Close Status as defined in the "StatusCode.ctl" ring and a close reason
	* A "DecodeCloseReason.vi" was introduced to decode the Close Status and the reason as delivered by the "Read.vi"
	* The "Write.vi" now can send binary an text data frames. 
	* The "Read.vi" was refactored so as to allow also binary data, to read the FIN bit and the close reason in case of receive "Connection Close" opcode. As a result now the calling code has the tools to handle the multi-framing and the Ping/Pong exchanges.
	* The example server and clients were updated accordingly
	* Introduced an enum typedef defining the data format type either text or binary. Other minor changes
	* added a VI to create a valid WebSocket URI staring from IP address, port and service name. This VI is intended to facilitate the code modifications required when upgrading from older versions of the library where the the client handshake VI was not taking a ws URI as input but IP address and port separately 
	* The Close method often follows the Read method returning the error 6066 "Closed by the peer". Checking of an input error within prevented it from sending Close frame in response, thus making the peer crash with the error 66 "TCP connection closed". This fix lets the Close message even if the error 6066 is present.