I had a data received by websocket client Now i want it to send to http server . Is there any method to store the data outside message event ?
Or
Can i convert websocket client back to http client ??
No, a WebSocket connection can't be "downgraded" back to HTTP.
But yes, moving the information out of the WebSocket event and starting a new HTTP request is quite trivial... though implementation details would (obviously) depend on language, environment etc'. i.e., a browser client implementation will be very different from a C client.
Note that the server can't initiate an HTTP request, but the server can ask the client to do so.
Related
I need to implement a tcp/ip client which connects to existing tcp server with a permanent connection. the client has to send multiple requests and response arrives asynchronously. I have use netty to do the integration part. I have to ensure that the response is done for the relevant request. How to implement this using apache camel.
rest()
.consumes("application/json").produces("application/json")
.post("/tcp")
.type(RequestBean.class)
.route()
.process(this::transformTcpMessage)
.to("netty://tcp://127.0.0.1:9898")
.endRest();
This is What I need to achieve. this TCP client need to have a permeant connection and server may response asynchronously. So I need to make sure that the relevant response has been send to the relevant request.
I'm looking for a way to wrap/intercept a websocket with a proxy that enriches the responses coming back from the web socket, as implicitly as possible.
For example, lets say I have a websocket endpoint: wss://stream.abc.com:1234 and I want to enrich the incoming json messages.
A brute force approach would create a new endpoint that's listening and creating a web socket to the remote socket for every connection and proxying the communication enriching the responses before sending them back to the client.
However I wonder if there's a more standard library that can do that, maybe with nginx?
Thanks,
Z
My requirement is if a browser sends the request to ServerBootStrap then the ServerBootStrap creates BootStrap (Client) and that client connects with a proxy server.
The problem here is to connect with Proxy Server we need to send first HTTP CONNECT method to open a tunnel from Proxy and BootStrap (Client) and then whatever request comes from Browser to Server, the server will send BootStrap(client) and all the communication should happen.
This will look like
Browser ->ServerBootStrap(Server)->BootStrap(Client)->ProxyServer(HTTP2)
Can somebody tell me how do I implement this for Http2?
How do I send Http CONNECT from a Handler for the First time while Client instantiating and If CONNECT gets 200OK from Proxy Server I will to remove Handler from channel pipeline?
Can we explicitly call any HTTP CONNECT request while adding a handler in Pipeline and getting the response to check the status?
--Can somebody answer ?
While I'm writing a service with grpc, I'm trying to compare http/2 with websocket by server side pushing mechanism.
I know for websocket, the client will send a request with Upgrade: WebSocket and Connection: Upgrade headers to server and establish the long-lived connection. Then server will send the data freely after the connection is established.
But for grpc, as it is routed upon http/2, from the wiki page, https://en.wikipedia.org/wiki/HTTP/2_Server_Push, it says the server would need to predict the potential requests the client would send, and send a PUSH_PROMISE frame as early as possible.
Here are my two questions:
Does it mean that the server would also need to receive a corresponding response(request) from client in response to this PUSH_PROMISE header to decide if client wants to receive or decline the certain push?
In Grpc, if I have a sever side streaming, say send a message every 1 second from server. Does it mean the server need to send a PUSH_PROMISE to client every 1 second or at least before every data frame that server pushes to client?
gRPC does not currently support/use PUSH_PROMISE.
Streaming RPCs in gRPC use HTTP/2 streams; the entire RPC is contained in a request/response in HTTP. The main difference is that HTTP/2 implementations generally allow such streams to be streaming and bidirectional (the client can send more in the request after reading part of the response), while in HTTP/1 that was hit-or-miss.
In gRPC the client will always initiate the RPC. But for server-streaming the server can then reply with multiple messages over time via the stream. This would be similar to the scenario you described with websockets.
I need to operate with a SOAP service from Erlang. SOAP implementation is not a subject, I have a problem with HTTP requests at a client side.
I use IBrowse as a HTTP client. This SOAP service uses a specific authorization mechanism, which relates an opened session to a client connection (socket). So, the client should use only one persistent connection to server (socket), and if it try to send a request via another socket (e.g., connection from pool) - authorization will fail.
I use IBrowse in this way:
Spawn connection process to server (ibrowse:spawn_worker_process/1)
Send request to server via spawned process with {max_sessions, 1} and {max_pipeline_size, 0}.
If I understand the docs right, this should use one socket for server connection with disabled pipelining, also, I use Connection: Keep-Alive header and HTTP version explicitly set to 1.0. But my connection is always closed after the response is received.
How can I use IBrowse (or another http-client) the way I described above?
I think you could that with hackney by reusing a connection.
Also gun is quite nice http client, easy to use, keeping connection, but with little less connection control.