I'm using the Lagom microservices framework and the Streaming requests and responses use websockets as the transport. However, the built in websocket client (netty) doesn't handle SSL connections. I understand there are various architectures where SSL termination isn't handled by Lagom itself that avoid this, but for our application we need TLS all the way to the endpoint.
The post (https://groups.google.com/forum/#!topic/lagom-framework/QcOvK8H3R94) suggests that akka-http websockets support TLS, but that isn't currently an option as a Lagom client.
This gist (https://gist.github.com/DaveDeCaprio/4db9d36a5e907fb5810c00e919347aa3) provides an example of an Akka HTTP websockets client for Lagom.
I don't include this as a full pull request in Lagom because it is still pretty hacky. The biggest issue is that the RequestHeader that is returned from a streamed call is a fake, generic Ok header. The actual HTTP call isn't made until the stream is materialized and run. This is due to a different in the way akka http and netty handle the websockets. This wasn't trivial to fix.
Related
I have just began using socket.io and I have some experience with express. I know socket.io has bidirectional communication while express is only client to server.
This made me think, why don't we just use socket.io with different namespaces and not use express at all?
In which cases should I use socket vs express?
In the case I need bidirectional communication, is it advisable to make the client -> server with express and then use socket for server -> client?
First off express and socket.io are pretty different things. Express is a full-blown web server framework. You use it for setting up a web-site, fielding http requests from a browser, fielding http requests for an API, etc...
socket.io is a communication layer that sits on top of the webSocket protocol and the webSocket protocol uses an http server to establish its initial connection. While there is a little bit of overlap between what you can do with socket.io and Express, they are more different than they overlap.
For example, if you're setting up a web-site, you couldn't do that with socket.io, one would use something like Express.
Now, if you have a specific programmatic need to communicate between an arbitrary client and a server, you have a zillion choices. If the client is in a browser and the programmatic interface is from Javascript in the browser, then you have fewer choices.
From the browser, using http ajax requests via Express is one choice. Setting up a socket.io connection and defining you own messages is another choice.
Reasons to pick socket.io over Ajax calls to Express from browser Javascript:
You need/want two-way communication over the same channel.
The client is sending a lot of requests to the server (the overhead for sending a socket.io message is lower than an ajax call, once the socket is already set up, so if you're sending a lot of messages, then socket.io messages are more efficient than http requests)
Reasons to pick Ajax calls to Express:
HTTP connections are stateless and short-lived which can make implementing high scale, multi-server implementations with failover and redundancy easier.
There are a wealth of tools to use for http connections from authentication libraries to data formats (MIME) to audio to video, etc...
You want your client to run in places where a long-connected socket.io during inactive periods of time may not be practical (perhaps mobile or battery operated devices).
You want to run in situations where there are proxies, firewalls or other network infrastructure that may not support long running webSocket connections or specifically disallow them.
You want a request/response model. HTTP is request/response where you get a specific response for each request and you know exactly which response goes with which request.
So, as you can see, there is no generic answer to this question. It really depends upon the specific of your communication, the interoperability you desire and the exact needs of your code.
Here are some other references on this topic:
Ajax vs Socket.io
Websocket vs REST when sending data to server
Using AJAX vs. socket.io socket messages
websocket vs rest API for real time data?
I am working with CoAP protocol on IoT but also I need a web service. I implemented the web service on Apache with HTTP protocol and a Proxy that converts CoAP-HTTP request and responses. But I don't want to use the Proxy to convert CoAP-HTTP. I want to implement directly CoAP web service. Do you have any idea about that. On Apache or different things. Just any idea?
As you wrote On Apache or different things, I will here talk about the second option :). To implement the CoAP server itself, I would recommend either
NodeJS with the CoAP package
Java implementation Californium, from Eclipse.org
More complete list available at http://coap.technology/impls.html#server-side, see Server-side
And then handle the communication with your Apache HTTP server via WebSockets and REST APIs.
coap.me is also great to run tests during development.
My group is evaluating HL7 Proxying and came across WS02 ESB. I have successfully configured an HL7 Proxy that seems to work well. Now my task is to secure the listening point with SSL (TLS specifically). This seems like something that the ESB should be able to handle. It can do HTTPS, Secured Web Services, etc. However, there doesn't seem to be a way to enable this with a simple check box for HL7 Proxying, nor am I finding any documentation on how to enable it manually.
Is it even possible to do secured HL7 Proxying within WS02 ESB?
Thanks in advance!
It seems WSO2 is using HAPI client for HL7 implementation and when I go through the code it seems TLS is disabled by default. Refer https://github.com/wso2/carbon-mediation/blob/master/components/business-adaptors/hl7/org.wso2.carbon.business.messaging.hl7.transport/src/main/java/org/wso2/carbon/business/messaging/hl7/transport/HL7TransportListener.java#L78
I need to build a server and a client that can exchange data in real time with a company's proxy between them. No one has the authorisation to amend the proxy's configuration (in order to allow the WebSocket protocol).
I would need a fallback technology such as long-polling.
Example: client is a user's PC employee. He needs to exchange data with the server, located in the cloud and separated by company's proxy.
Ideally, I would use WebSocket with SSL, but I know some proxies are not configured for WebSocket messages and thus could reject the connection.
The app would therefore switch to another push technology such as long-polling, increasing the chances of getting a successful connection (is 100% guaranteed with proxies? Giving that there are several types of proxies...)
Are there any libraries/frameworks proposing such features?
Usually, secure WebSocket connections do fine through proxies.
In .NET you have SignalR
In node.js you have socket.io
I'm writing a RESTful API service, that will only work through HTTPS protocol. What kind of response code should be returned if the request comes via HTTP?
"301 Moved Permanently" where the server redirect the client from a http to https. This is the most commonly used pattern and what I would recommend you to implement on a server level. Implementation of this depend on the webserver your have and I would guess that there is plenty of good guide online to your specific server.
This will also tell the client to switch from HTTP to HTTPS Permanently.
If the question was more related to method rather than HTTP/HTTPS then "405 METHOD NOT ALLOWED" would be the correct choice. This is what you should respond to a client if the client is not not allowed to call the method itself. This would be misleading as a first step since the HTTP/HTTPS protocol is the problem and not the method (Get, Post, Put etc.) utilized by the client.
426 Upgrade Required. This suggest that https should be used.