Looks like Google App Engine didn't support it yet as of early 2015. Does Heroku support it? Wondering what does it take, shouldn't it work if we deploy all appropriate dependency and use the right port? (assuming authentication will be taken care of)
No, Heroku doesn't support HTTP/2 required for gRPC to work.
HTTP/2 is not currently supported on Heroku although this may change in future. You can find out about our currently supported HTTP protocols here: https://devcenter.heroku.com/articles/http-routing#http-versions-supported
Heroku only accepts incoming requests on Port 80 and Port 443. That'll probably be the limiting factor.
Related
I have a process that runs in California that wants to talk to a process in New York, using Stomp over Websockets.
Also note that my process is not a web app, but I implemented a stomp over websocket client in C++, in order to connect things up to my backend. Maybe this was or wasn't a good idea. So, I want my client to talk to the server and subscribe, where their client pushed messages.
I was implementing my own server when I saw that ApacheMQ supported Stomp over Websockets. So, I started reading the docs.
It says with the last line under 'configuration' at
http://activemq.apache.org/websockets :
One thing worth noting is that web sockets (just as Ajax) implements ? > the same origin policy, so you can access only brokers running on the > same host as the web application running the client.
it says it again in several related searches such as http://sensatic.net/activemq/activemq-54-stomp-over-web-sockets.html
Is this a limitation of the server or the web client?
With that limitation, if I understand right, the server is not going to accept websocket connections from a client, of any kind, that is not on the same machine?
I am not sure I see the point of that...
If that is indeed its meaning, then how do I get around it in order to implement my scenario?
I've not found that bit of documentation you are referring to but from what I know of the STOMP implementation on the broker this seems incorrect. There shouldn't be any limit to the transport connector accepting connect requests from an outside host by default and I don't think the browser treats the websocket requests the same as it does other things like an Ajax case in terms of the same origin policy.
This probably a case that is best checked by actually trying it to see if it works, I've connected just fine from outside the same host using AMQP over websockets on ActiveMQ so I'd guess the STOMP stack should also work fine.
Currently if I scan(from both UI and CLI) using ZAProxy it sends HTTPS Traffic using HTTP1.1 version, Do we have any Support or Workaround to send HTTPS Traffic using HTTP2.0 version in ZAProxy.
Any help on this is much appreciated
No ZAProxy does not support HTTP/2 at this time.
The Paros networking layer used by ZAP is old, and lacks support of modern options such as HTTP/2. They planned to replace this but there is no ETA as of now.
refer the thread : https://github.com/zaproxy/zaproxy/issues/1765
I have recently been sharing the connection of my mobile device to my laptop, when i'm out and about, through the use of an app called netshare. It provides a https proxy I believe through which it acts as a network repeater?(not sure about this part). I can access webpages and such quite easily. However, I have realised that I cannot connect to some apps. For example, I cannot use spotify. Installing some other apps like games etc also prove to fail. I have done a bit of research and found that apparently I could only surf the web with a https proxy. However, I found this to be unambiguous. Does this mean that I can only make https requests? Or is this because of https using TCP over UDP? What are the limitations and what can I do to possibly solve it?
Thanks
I am searching for a server push technology for my web application.
I would like to use a similar technology as StackOverflow, as that one is working very well.
So, are there any suggestions?
For server-to-client push Server-Sent Events is a better choice than WebSockets. GitHub uses SSE for automatically showing new comments, pull requests, etc.
SSE is HTTP-compatible, so it will work with proxy servers and you won't need HTTPS to have it working in practice (e.g. plenty of mobile operators have a HTTP proxy that breaks unencrypted WebSockets, but SSE works fine).
SSE connection is lightweight and quick. There's no extra handshake and connection upgrade procedure. If you have SSE on every page, then your server will have less work to do.
SSE protocol is super simple. You don't need special web server or library for it, and it can be polyfilled for old browsers.
I suggest you have a look at QWebSockets, if you control the server-side.
Otherwise, socket.io is a good candidate.
There are also ghosted services like Pusher and PubNub, which are free for a moderate number of push messages.
Need to be able to continuously receive calls when a Chrome webpage is open. How do I do that even for users who are inside a strict enterprise network?
WebSockets? (but there's the proxy problems that doesn't know what wss:// is)
HTTP? (but will I have to poll?)
Other?
Since you included the "vLine" tag, I'll reply with some information on how our WebRTC platform will behave in an enterprise network. vline.js will use a secure WebSocket by default if the browser supports it and fall back to HTTPS long polling. As described here, the secure WebSocket may work depending on the exact proxy configuration. Feel free to test it out by using GitTogether or creating your own vLine service for testing.