I'm trying to use websockify to allow javascript executed in a browser to talk to my hand-written server. When using the latest versions of Chrome and Firefox, I get the following error message from websockify:
Client must support 'binary' or 'base64' protocol
After looking at the code, I've determined that websockify delivers this message and closes the socket whenever both of these protocols fail to appear under the Sec-Websocket-Protocol header received from the client. When I look at the raw data transmitted by Chrome it doesn't even send this header. Is this a problem with Chrome or websockify, or am I failing to provide some information when opening the websocket in my javascript? Or is there some other explanation?
You need to provide the protocol list as part of the object constructor:
var ws = new WebSocket(uri, ['binary', 'base64']);
If you use the websock.js library included with websockify then it will handle this for you. However, note that websock.js does not provide the standard WebSocket API but rather a streaming oriented API. Even if you use a raw WebSocket connection to websockify, note that you will still need to do message reconstruction because normal TCP does not have a concept of messages so the messages chunking from onmessage will be essentially "arbitrary".
Related
I am hoping someone can point me in the right direction. I have a CF2021 Server which uses a Node.js websocket server and CF pages (via javascript) as a client. Messages from user to user work as expected, so no issue there.
This CF Server also has a custom API built using CFML that handles and routes inbound SMS messages. My question is; what would be the best way to send the SMS message (by now its json) to the Node.js websocket to it can send it to the user(s).
I tried using the same javascript that the browser client uses, but it appears that the CFML API script is "browser-less", so that doesn't work, or should it?
I thought something like Apache Groovy may be the solution, but I am having difficulties with any websocket example I have found.
Any suggestions would be greatly appreciated.
thanks in advance
Flow matters.
If you want to handle an incoming message by delivering it to all currently logged in users who are subscribed to messages of the current sort: set up your message handler to deliver using lucee/adobe-coldfusion websockets. Be forewarned, Lucee takes some setup time, but once running, it is a great solution.
If you don't need immediate delivery, or you need a super simple solution: I actually have had some success with "Long Polling" you just have to remember to use "flush" early in the request, before any pause/sleep, then loop your message lookup requests for new data, with a 1-5 second delay between each loop. Once new data is found, I like to return the request to the client, close that polling request and start a new polling request using the client side. I typically won't poll for more than 60 seconds. Even if the returned json object is empty.
I am try to implement a basic web socket app by following this tutorial:https://spring.io/guides/gs/messaging-stomp-websocket/
However, in that tutorial there was a client UI implementation. I don't want to use UI. Instead of the UI, I want to use a websocket client extension in Chrome for sending and seeing messages.
All codes same with the tutorial(except the UI part since I'dont want UI), so I don't rewrite all codes here.
I am able to connect and send message to the url: ws://localhost:8081/gs-guide-websocket for example,
However, I can't get response with this url: ws://localhost:8081/topic/greetings. (I use this URL for getting responses by subscribing it. Because this topic/greetings path used in the UI side of that tutorial for subscription)
The Chrome extension that I used is Simple WebSocket Client.
Why I couldn't subscribe the ws://localhost:8081/topic/greetings url? and How can I get messages from the server by using the Chrome client websocket extensions?
Your application works with STOMP and SockJs, this plugin does not support that. It only works with ws. In this example, you can write a simple ws endpoint for your application:
example simple ws endpoint
I want connection to a websocket server wss://fm.missevan.com:3016/ws。i use online websocket tool http://www.websocket-test.com to do it, but in edge browser, it's response is ok and in chrome ,the response is 403 forbidden.
Actually, i use GO language to connection wss://fm.missevan.com:3016/ws,I tried many websocket library but all failed.
I checked the request header of connected browser, there are no special fields. so who can analyze the reason of this, thanks
I want to send SMS from AngularJS web application using Ozeki sms gateway. Can anyone tell me how to do this? pr suggest me some reference link or code sample.
Plain sending
Assume we skipping other protocols available inside Ozeki Sms NG product (like SMPP, Email, DB etc), and getting to HTTP protocol only, you can go this way:
Prerequisites:
Figure out best way for you to make HTTP request to send SMS
(I'm not AngJS guy so may be there are already few ways to make HTTP-request from Angular, but at least any Ajax method passing params to executing PHP-script for making HTTP request (with curl, file_get_contents) will be totally Ok).
Make sure your Ozeki SMS server is reacheable via IP/domainname etc by your PHP-script so your code can reach its endpoint.
Doing it:
Inside Ozeki install service provider like HTTP Client
http://www.ozekisms.com/index.php?owpn=195&info=service-provider-connections/http-client-connection
or HTTP Server (more powerful version of HTTP Client allowing call back URLs)
http://www.ozekisms.com/index.php?owpn=197&info=service-provider-connections/http-server-connection
Then according (to docs) execute request like
http://server_ip:9501/api?action=sendmessage&username=________&password=________&originatior=__________________&recipient=__________________&messagetype=SMS:TEXT&messagedata=______________
*Some fields are not necessary, it may vary depending on Ozeki version you use.
** port 9501 - is a default Ozeki HTTP port which may be changed in general settings, also it has HTTPS port as well. Basically the correct port is the same which you already use when accessing Ozeki Web GUI.
After executing sending request (try from browser or from something like Postman first) you should get responce in XML format informing you about result of your transaction.
Possible next step... DLRs
Getting delivery reports (if supported by your operator) is a common "i want it too" question.
In case you need them - there is great embedded feature inside "HTTP Server" connector (mentioned above).
Here you can see more details
http://www.ozekisms.com/index.php?owpn=431
"reporturl" - is a field you may use to set kind of "call back url". In other words in this optional field you may specify full URL and list fields to be passed along. So you only have to create your own endpoint to catch them (as GET request from Ozeki server) and use inside your software.
The most use cases for http/2 server push is to pre-emptively push assets files (such as javascript and css files) to browser. I am wondering can http/2 server push be used to send dynamic payload such as JSON documents to client application? From the http2-spec, it doesn't mention anything about this. Can anyone elaborate more on this? Why or why not?
HTTP/2 is not intended as a replacement of websockets in that you make a request (e.g. a web page) and may get several resources back (e.g. The web page, the CSS needed to display the webpage, JavaScript needed to run that webpage... etc.).
HTTP/2 is therefore not truly bidirectional in that it still responds to an initial request.
So if you're intending to send the JSON request in response to the initial request then that's fine - it's just another resource in much the same as CSS and javascript.
However if you're intending to keep the channel open to continually send further JSON payloads to keep your page up to date then that's not what HTTP/2 is intended for. That's what websockets are for.
This question has some further details on HTTP/2 versus websockets: Does HTTP/2 make websockets obsolete?
Yes, you can use HTTP/2 Push to send any type of assets. But keep in mind the following:
As BazzaDP said, HTTP/2 Push is not a push notification mechanism. But HTTP/2 is excellent for doing long polling, and then you have content-encoding compression, encryption, HTTP headers and flow control, so for 90% of the cases you can and probably should skip websockets anyway. Notice that when doing long polling, HTTP/2 Push is not required.Also notice that there is something called Server Sent Events which sort of is the browser-endorsed version of long polling.
HTTP/2 Push is so far transparent to the application. Meaning that you have to do the Push and do a request for the resource from your application.
For now, only cacheable things are made available to the application. That means that you need to set cache headers in the dynamically generated JSON response. Probably you can set a short expiration time, or a long one but under a dynamic URL.