LabVIEW HTTP Client API VIs does't return the 101 code

[ANDRÉ_CARVALHO]

Hello everyone.

The HTTP protocol provides that code 101 is used to exchange header messages to perform a connection upgrade. Typical cases are upgrades for establishing Websocket connections. See https://tools.ietf.org/html/rfc7231#section-6.2.2.

I am interested in using the HTTP API to establish a Websocket connection.

In fact, the API provided by MediaMongrels at https://www.mediamongrels.com/labview-websockets-api/ does an excellent job of establishing unsecured connections, but I still need to implement a SSL encrypted websocket.

So I thought that, as the HTTP Client API supports the HTTPS protocol, if I could establish a websocket link using this API, perhaps it would solve all the encryption part by itself and I would be able to establish a connection using the WSS (Secure Websocket) protocol.

With that goal in mind, my first step was to try to access an unsecured websocket server using the GET.vi and HEAD.vi VIs. However, I realized that these VIs do not return anything when the HTTP code is 101. This, of course, makes my application unfeasible.

I'm sure the problem is with the HTTP API VIS, as I was able to get all the answers using only TCP.

I am using LabVIEW 2017, and I would like to know why this part of the HTTP standard was not implemented in the LabVIEW HTTP API. Was it on purpose? Are there any plans to include these API features?

Thank you!

PS. For those interested in reproducing my results, check the attached files.

This VI attempts to establish a connection with the websocket server installed at localhost: 8025 by three different methods: through the API developed by MediaMongrels, directly via TCP, and via http.

For testing purposes, I have included a small websocket server that can be installed on the local machine, listens to the port 8025 and echoes all received messages.

0. You need java installed to run the server.

1. Extract the file EchoServer.jar

2. Use the windows cmd, navigate to the folder where the file is located and execute it as follows:
java -jar EchoServer.jar

3. Run the VI and test different types of ws connection.

[PhillipBrooks]

---

The 101 (Switching Protocols) status code indicates that the server
   understands and is willing to comply with the client's request, via
   the Upgrade header field (Section 6.7 of [RFC7230]), for a change in
   the application protocol being used on this connection.

---

I read this as the Server is to return 101 to the client ( LabVIEW ) if the Upgrade header field in the request.

Are you including an Upgrade header option in your request? 

Are you receiving a 426 code?

The Server should return code 426 ( which includes an upgrade header field) if the requested protocol is refused.  

6.5.15. 426 Upgrade Required

   The 426 (Upgrade Required) status code indicates that the server
   refuses to perform the request using the current protocol but might
   be willing to do so after the client upgrades to a different
   protocol.  The server MUST send an Upgrade header field in a 426
   response to indicate the required protocol(s) (Section 6.7 of
   [RFC7230]).

[ANDRÉ_CARVALHO]

Hi Philip, 

thanks for your feedback. 

Yes I am sending this headers:

And I receive no answer at all. Just this error code:

Note that the problem is not with the server, because I can stablish a connection using just the TCP VIs. Is the HTTP API that seems to have a problem...

[PhillipBrooks]

Error 363529 = "LabVIEW: The server closed the connection prematurely."

That sounds like LabVIEW never reached the Server. Maybe some sort of firewall setting is blocking access to the Server?

I can't see the details in your VI because I use LabVIEW 2016.

[ANDRÉ_CARVALHO]

Hi Philip, 

I think this is not the case, since I can access the server by two other different ways. If you wannna give a shot, please find attached my VI saved to LV 2015 version!

Regards!

André

[Achuthaperumal]

Hi,

Have you resolved the error? I'm facing the Same error! Can anyone help?

[IlluminatedG]

The HTTP client APIs are not usable to do websocket communications. You'll need to use one of the websocket libraries available from VIPM (I believe there's a shortcut to install one already in the data communications palette).

The HTTP Client implementation is meant to do traditional http exchanges: open connection, send request, read response, and close. Of course this doesn't work for websocket connections and there is no means to have a handle back to be able to send anything over the http session connection.