-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Websockets support #319
Comments
No, we don't currently support websockets. |
This is very useful information as I will stop trying to find a workaround for this. I guess I will have to refactor my push microservice to use HTTP2 somehow |
Going to reopen just to track the feature request. |
Traefik claims to support HTTP2 as well as websockets. What is the limitation here... |
The limitation is we don't support the websocket protocol. :) It needs to get implemented, probably just as a new L4 filter that sits in front of the tcp_proxy filter. |
Based on gitter conversations with @mattklein123 make a new filter, use the http1 codec, handle the “upgrade", then just transition to straight tcp proxy semantics. Could probably just implement as as filter that sits in front of tcp_proxy, or use the existing http1 codec_impl to do the initial handshake then just pass through data to tcp_proxy. |
@rshiram do you have an example JSON confirm you could share? |
@andrewwebber this feature is not implemented yet. I was merely logging our conversations in this topic. |
Is there a potential timeline or update whether or not Envoy will support websockets? |
@jtaylor32 no, no update. Need someone to sign up to implement this. |
@rshriram I looked through the code and IMO this is the easiest/cleanest way to implement the required functionality. Let's discuss here if there are questions. cc @htuch
These are rough notes but should be good enough to get started. LMK if you have more detailed questions and we can figure it out. |
It's a pass through. If your backend doesn't speak websockets, then Envoy
can't do anything can it?
On Wed, Jun 21, 2017 at 5:20 PM politician ***@***.***> wrote:
@mattklein123 <https://github.com/mattklein123> Can you clarify whether
the plan is to terminate HTTP/WebSockets at envoy or whether you're going
to pass the protocol through? I can't tell from the last bullet whether a
backend needs to be a full HTTP/WebSockets server or just a basic TCP
socket server that supports a handshake containing the upgrade headers.
For my use case, the latter is preferable.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#319 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AH0qd3bAlf5roVtMaFS5tf4yunADTkqGks5sGYkmgaJpZM4Lb2a->
.
--
~shriram
|
Why can't Envoy terminate the websockets and speak plain TCP to the backend? This seems a reasonable ask. |
I think there is Nomenclature mismatch.
@politician simply put, if you have a nodejs websockets app behind an Envoy
for example, you can talk to Envoy via websocket and Envoy will talk to
your app via websocket.
If your nodejs app doesn't support websockets, then Envoy will refuse
websockets connection from clients. Similarly, if the client speaks just
http (not websockets), and the server speaks only websockets, then Envoy
will refuse client connection for that specific route.
On Wed, Jun 21, 2017 at 8:52 PM htuch ***@***.***> wrote:
Why can't Envoy terminate the websockets and speak plain TCP to the
backend? This seems a reasonable ask.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#319 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AH0qd8T2DwzHcCbu6Eo-COj326xXhT9Dks5sGbrCgaJpZM4Lb2a->
.
--
~shriram
|
I think what's being asked here is that you have a nodejs TCP application (to continue the example), which does not speak HTTP or websockets. We have a browser client that speaks websockets. Envoy could act as a bridge from the client to the nodejs TCP application. Is this what you were thinking of @politician? |
If there is a use case that involves WS <-> TCP without the upgrade headers, that will be trivial to implement via a configuration option, so we can cross that bridge when we come to it. |
This is the first of the PRs for enabling websocket support in Envoy. Currently, we strip upgrade and connection headers. For websocket support, we need to allow these headers to pass through if Connection: upgrade and Upgrade: websocket. c.f. #319
Automatic merge from submit-queue. [DO NOT MERGE] Auto PR to update dependencies of mixerclient This PR will be merged automatically once checks are successful. ```release-note none ```
Signed-off-by: Yuki Ito <mrno110y@gmail.com>
Years later now, but does anyone know if this is possible now? I have my own hand-rolled application for WS<->TCP communication, but I was hoping that I could replace it with Envoy. |
Not sure where to ask a question - the question is to what extent does envoy act as a proxy for websocket ? After the Upgrade handshake is done, does it ever look into the websocket framing itself / does it care about the websocket data being proper - or does it just treat it as a tcp after wards ? The reason for asking is to know whether I can use an http upgrade sequence and then send non-websocket data over that connection assuming my client and server are in my control - will envoy have any unhappiness with that ? |
Signed-off-by: Mike Schore <mike.schore@gmail.com> Signed-off-by: JP Simard <jp@jpsim.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com> Signed-off-by: JP Simard <jp@jpsim.com>
Does Envoy support websockets as I seem to be having some issues connecting from a golang client with a golang Backend server.
The text was updated successfully, but these errors were encountered: