Does rikulo stream v 0.7.2 support web sockets with different channels?
I have seen so far only examples with static resource files.
To handle Web Socket, you can use WebSocketTransformer to upgrade HTTP connection to WebSocket connection:
new StreamServer(uriMapping: {
"/cmd", (HttpConnect connect) =>
WebSocketTransformer.upgrade(connect.request)
.then((websocket) {
websocket.listen((evt) {
websocket.add("Server received: $evt");
});
return socket.done;
})
}).start();
Note: Web Socket is supported directly since Rikulo Stream 0.8.0. Please refer to the WebSocket Handling section.
Related
I now receive an rsocket connection in my spring project, and then I want to get its remote address and port, how should I get it?Similar to using socket.getRemoteSocketAddress() to get the remote address of the socket.
#ConnectMapping
public void connectMapping(RSocketRequester requester) {
// there is a resockt connect, how can i get the remote host from it
RSocket rSocket = requester.rsocket();
// TODO
logger.info("host port");
}
Unfortunately, I think even if you grab the RSocketRequester in #ConnectMapping or #MessageMapping method it is an internal detail. io.rsocket.core.RSocketRequester via RequesterResponderSupport holds the DuplexConnection which represents a connection over tcp, web socket or in-process. It is not exposed via a public API.
This is a worthy request but you will need to file a feature request to get this added unless I'm missing something obvious.
It isn't clear that there is a hook in https://docs.spring.io/spring-boot/docs/2.3.0.RELEASE/api/org/springframework/boot/rsocket/server/RSocketServerCustomizer.html to let you see the DuplexConnection (tcp or web socket etc) as it's established.
We have configured our Jenkins server to use a fixed port and JNLP 4.
Our info sec team has flagged that if one were to open a web browser pointing at the JNLP port, the internal properties below are listed which includes the internal ip of the Jenkins server.
Jenkins-Agent-Protocols:
Jenkins-Version:
Jenkins-Session:
Client:
Server:
Remoting-Minimum-Version:
Is this information necessary? Is this something which can be suppressed?
From the source: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/TcpSlaveAgentListener.java
It looks like there is no mechanism to turn it off, and according to the comments, it seems to be only for testing:
String header = new String(head, Charsets.US_ASCII);
if (header.startsWith("GET ")) {
// this looks like an HTTP client
respondHello(header,s);
return;
}
// otherwise assume this is AgentProtocol and start from the beginning
(...)
/**
* Respond to HTTP request with simple diagnostics.
* Primarily used to test the low-level connectivity.
*/
private void respondHello(String header, Socket s) throws IOException {
(...)
If infosec requires you to turn this off, you might need to open a support ticket with cloudbees.
I'm trying to implementing a proxy server with Dart: a web app running on the browser makes a request to my dart server app (proxy server) running locally, and then the proxy server makes a request to the external server. I then add CORS headers to the response that is going to be sent back to the client (web app).
Here's how I implemented the proxy server:
import 'dart:io';
import 'dart:convert';
main() async {
var server = await HttpServer.bind(InternetAddress.ANY_IP_V6, 8080);
print('Server listening on port ${server.port}...');
var client = 0;
HttpClient proxy;
await for (HttpRequest request in server) {
print('Request received from client ${++client}.');
// Adds CORS headers.
request.response.headers.add('Access-Control-Allow-Origin', '*');
proxy = new HttpClient()
..getUrl(Uri.parse('http://example.com/'))
// Makes a request to the external server.
.then((HttpClientRequest proxyRequest) => proxyRequest.close())
// Sends the response to the web client.
.then((HttpClientResponse proxyResponse) =>
proxyResponse.transform(UTF8.decoder).listen((contents) =>
request.response
..write(contents)
..close()
));
print('Response sent to client $client.');
}
}
This works fine most of the times, but sometimes the client only receives part of the response. I think sometimes the request.response.close() is being executed before the request.response.write(contents) finished executing, and so the response is sent before it has finished writing the contents.
Is there any way to solve this and only send the response once the contents have been written? Thanks.
You close the response after you receive the first chunk of data (..close()) . You should remove the close() from there and listen to the close event of the proxyResponse stream and close the response from there.
Problem
I have added support for http compression in our self-hosted OWIN/Katana Web API OData 4 service but I do not see how to support compression in the .NET client. I'm using OData libraries v6.5.0 and I need to support compression/decompression in the client (OData v4 Client Code Generator). I am using Deflate encoding for the compression via an ActionFilter. Everything compresses correctly on the server as confirmed via Fiddler but I do not know how to configure the client to support this now that the OData client uses the Request and Response Pipelines instead of the now defunct WritingRequest and RecievingResponse events that once supported this very scenario.
Attempts
By experimentation I found that I can hook into the ReceivingResponse event on my DataServiceContext and then call ReceivingResponseEventArgs.ResponseMessage.GetStream() but I don't know what to do to overwrite the message content correctly. If I CopyTo() on the stream, I get a null reference exception at Microsoft.OData.Core.ODataMessageReader.DetectPayloadKind(). I presume this is because the stream was read to the end and the position needs to be set back to zero but I cannot do that because the stream also throws an exception when setting the position back because it says it does not support seeking. I presume this is simply due to the stream being read-only. Even if I could copy the stream to decompress it successfully, how do I modify the response message content with the decompressed content? I don't see any hooks for this at all in the RequestPipeline or ResponsePipeline. To clarify, I want to decompress the response message content and then set it for the materialization that occurs soon after, how might I do that? Extra credit for how to also send compressed requests to the OData service. Thanks!
OData client use the HTTPWebRequest and HTTPWebReponse, which supports the compression well. Try setting the AutomaticDecompression of HTTPWebRequest to Deflate or GZip, in SendingRequest2 pipeline event, like this:
private void OnSendingRequest_(object sender, SendingRequest2EventArgs args)
{
if (!args.IsBatchPart) // The request message is not HttpWebRequestMessage in batch part.
{
HTTPWebRequest request = ((HttpWebRequestMessage)args.RequestMessage).HttpWebRequest;
request.AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate;
}
}
Then in response, HTTPWebResponse will decompress the stream automatically, before the materialization work.
i run in some problems with my jersey rest api and a client.
This is how im using the methods on a server side:
#POST
#Path("/seed")
#Produces(MediaType.APPLICATION_JSON)
#Consumes(MediaType.APPLICATION_JSON)
public Response addSeed(Seed seed) throws InterruptedException {
if (!Validator.isValidSeed(seed)) {
return Response.status(400).entity("{\"message\":\"Please verify your JSON!\", \"stat\":\"failed\"}")
.build();
}
save(seed);
return Response.status(200).build();
}
If i run a Jersey client in a while(true) loop, there are connections open and won't close. So im running into a problem i have a lot of connections open and my network crashes. So i can't use my server any more. After the connections are closed i can connect to the server.
This is a client:
ClientConfig config = new DefaultClientConfig();
Client client = Client.create(config);
WebResource service = client.resource(getBaseURI()).path("api/seed");
while (true) {
ClientResponse cr = service.header("Content-Type", "application/json").post(ClientResponse.class, seed);
System.out.println(cr);
cr.close();
My Questions are:
What can i do on the server side, to prevent clients open a new connection?
How can i specify a max number of connections?
And how should i implement the jersey client to reuse open connection?
I don't know of a way to limit Jersey resources at the web-app level. If you upgrade to GlassFish EE, you can make your resources EJBs #Stateless #StatelessDeployment(maxInstances=16)
The pile up of connections could be because of Keep-Alive settings. In Tomcat 6 there are two you can tune your connector with:
maxKeepAliveRequests, which defaults to 100. It's the maximum number of HTTP requests which can be pipelined until the connection is closed by the server. Setting this attribute to 1 will disable HTTP/1.0 keep-alive, as well as HTTP/1.1 keep-alive and pipelining. Setting this to -1 will allow an unlimited amount of pipelined or keep-alive HTTP requests.
keepAliveTimeout, which defaults to connectionTimeout which defaults to 60k ms. It it the number of milliseconds this Connector will wait for another HTTP request before closing the connection.