I tried the SignalR(Self-Host) and seems it wraps the message with its own payload in JSON.
Is it able to handle SignalR raw message?
I wanna set the WebSocket sub-protocol to "wamp"
I need send & receive the message in raw format as it is on client side
I don't need any fallback support, only WebSocket and I wanna turn off all the other fallback features
Br
As far as I know, SignalR does not support WebSocket sub-protocols, It can handle strings if you use the PersistentConnection API, that contains a method to receive String :
Task OnReceived(IRequest request, string connectionId, string data);
If you need WebSockets with a custom protocol, you can use XSocket.NET : https://github.com/XSockets
Related
I am playing around with Spring WebFlux to get a taste for reactive API's , however I am struggling to find a solution to "POST" data to a WebFlux endpoint from the JavaScript EventSource API .
My endpoint looks like this :
#PostMapping(value="/start/{id}", produces = MediaType.TEXT_EVENT_STREAM_VALUE , consumes=MediaType.APPLICATION_JSON_VALUE)
public Flux<Integer> startProcessing(#PathVariable("id") Long id, #RequestBody ProcessDetails process)
And I am easily able to hit the endpoint using POSTMAN , but the JavaScript EventSource api used to get an eventSource is not allowing to send a POST body . The request sent is always a GET request.
<script>
var source = new EventSource("/start/34");
...
How can I POST content to a WebFlux endpoint from the browser?
EventSource and in general, Server Sent Events are unidirectional, from server to client (see reference).
If you'd like to POST data from a browser to the server, any regular AJAX POST will work.
Note that with your current endpoint setup, the browser should send a POST request with a JSON body and then receive an infinite stream of SSEs.
If you'd like to have a bidirectional stream of messages, then WebSockets is the answer here. Spring WebFlux currently supports raw WebSockets, so no Sock.js/STOMP abstraction is available for now.
I want to write a simple "web service" that I can use Mirth to send HL7 messages to. This "web service" could be as simple as a CGI script, and would just need to accept the HL7 message as a string (and possibly a couple of other values) as a POST request using Mirth's HTTP sender.
This seems simple enough, but how should this "web service" send back the ACK to let Mirth know if everything is OK or something went wrong? Is there a specific format that Mirth is expecting as a response? Or is there some way to tell Mirth what to expect?
Note: I do not want to use Mirth on the receiving end.
The short answer is that it's completely up to you... Mirth Connect can accommodate any response (or lack thereof) and perform custom user-logic to decide whether the response is "successful" or not.
You could have your external web service generate an HL7 v2.x ACK and send that back. Then on the HTTP Sender side, make sure your Response data types are set to HL7 v2.x, and enable "Validate Response" in the destination settings.
You can also have your web service generate a completely custom response and do custom validation on the MC side. For example if you have your web service send back a response like this:
{
"success": true,
"message": "Message received successfully."
}
Then you can set your Response data types to JSON, and do this in the response transformer:
if (msg.success !== true) {
responseStatus = ERROR;
}
responseStatusMessage = msg.message;
You can also validate purely on the response status code. By default with an HTTP Sender, the message status will be set to SENT only if the HTTP request returned with a status of < 400. Anything else and the status will be left as QUEUED (or ERROR if queuing is disabled).
You can override that behavior in the response transformer though. Maybe you only want it to be SENT if the status is specifically 200 (and not other 2xx or 3xx codes). Set your Response data types to Raw (so that the response transformer will execute even when there is no response), and do this in the response transformer:
var responseStatusLine = $('responseStatusLine');
var responseCode = parseInt(responseStatusLine.split(' ')[1], 10);
if (responseCode != 200) {
responseStatus = ERROR;
responseStatusMessage = responseStatusLine.substr(responseStatusLine.indexOf(' ')).trim();
}
Situation: For a web application using SignalR, for sending messages from server(an Azure WebRole) to a browser, I need to access a browser cookie before sending each message to the browser. The cookie would contain some info to process/decode the message before sending it (I can't do this in java script, due to access complexities of decode algo).
The scenario would be to have the access to the cookie as soon as the message is ready in the server --> decode the message --> send the message.
Question : Does it make sense to ask the browser to give me the cookie before each message that I want to send to the browser? Or Does it ruins the whole idea of SignalR (being a always connected tcp)?
If it does make sense, then how would I go about this? How can I access cookie in the Hub?
If this would not be possible then I'd have to store the decode information in some persistent storage in the server.
P.S: I'm pretty new to SignalR, so pardon me if the question is too naive.
Cookies seem like a reasonable way to communicating immutable data from the client to the SignalR server. You can read a cookies from inside a Hub as follows:
public void MyHubMethod()
{
Cookie cookie = Context.Request.Cookies["cookieName"];
// ...
}
Just be aware that the request referenced by Context.Request will be very long running in the case of WebSockets, so don't expect to pick up any changes that may be made to cookie after you initiate the SignalR connection.
I am a student who just started using Netty!
I am building a server that communicates with android and iOS. The primary task of my server will be sending and recieving JSON files with images(10 jpegs) and texts(less than 100 character).
My server's framework is Netty.
I built my server from "HttpUploadServer" from the Netty 4.0.6 example jar. As my server's primary task is to upload and download JSON files, I only used multipart POST part from the example.
So here is my question.
Netty's HttpRequestEncoder and HttpResponseDecoder turns Http requests into ByteBuf and ByteBuf to responses.
However, what happens when I try to communicate with JSON? Does the encoder and decoder turn JSON into a ByteBuf and sends it?
What is the normal way Netty users send and recieve JSON through HTTP?
For sending and receiving JSON messages, you don't need to add any Handlers. Http Encoders/Decoders are enough.
Here is a example that uses JSON to send and receive.
http://kevinwebber.ca/multiplayer-tic-tac-toe-in-java-using-the-websocket-api-netty-nio-and-jquery/
Regards,
Rama Krishna.
I have:
Request request = new Request(Method.GET, "https://www.awebsite.com/login");
Client client = new Client(Protocol.HTTPS);
Response response = client.handle(request);
...
response.getEntity().write(System.out);
But I don't know how to set the login parameters...
I want code that
does the escaping etc
can switch between get/post easily
Being a REST-based platform, I'm thinking I might need to use some parameter "representation" but that seems a bit strange. I'd think it would be common enough to build in this representational exception.
If by "login parameters" you mean sending credentials using Basic HTTP Authentication, it's done using Request.setChallengeResponse() like so:
Request request = new Request(Method.GET, "https://www.awebsite.com/login");
request.setChallengeResponse(new ChallengeResponse(ChallengeScheme.HTTP_BASIC, username, password));
This will work for any Request, using any HTTP method.
If, however, the server to which you're trying to authenticate expects credentials using some protocol other than Basic HTTP Auth, then you'll need to explain that protocol -- i.e. does it use cookies, headers, tokens, etc.
BTW, you might get faster/better responses by posting to the Restlet-Discuss mailing list; I've been on there for a year and a half and it's a great community.