Feature request: Websocket endpoint for service logs

[cghislai]

There is already a websocket endpoint to attach to a container.
Now that service logs are available in the API, I'd be happy to be able to use websocket to fetch them.
Hijacking a TCP connection is not something we can easily do in a browser.

[boaz0]

@cghislai can you tell what is your use case here? What will web-socket solve for you?

Thanks.

[cghislai]

I can't use the hijacking technique to gather container/service logs in a web browser javascript context.
Neither the XMLHttpRequest interface, neither higher-level API allow me to do so - unless Ive missed something.

Websockets however are already handled by most web browsers and web servers. No special technique is required and existing libraries could be leveraged to gather logs.
A websocket endpoint for service logs would allow me to fetch logs using the XmlHttpRequest or fetch API. Just like the exsting /ws endpoint for container logs.

[ghost]

@thaJeztah @boaz0
it still relevant, i am willing to open PR?

[cpuguy83]

Logs don't hijack the tcp connect, IIRC.
The main thing is that we have this multiplexed stream format that requires demuxing on the client.

What I'd like to see is for the API to not use this stream format if a single stream (egg stdout) was requested. Then you can make two requests, one for each stream.
If we support http2 these requests would go over a single connection.

[cpuguy83]

btw, the attach endpoint for websockets has always looked wrong to me since everything seems to be sent down a single stream and there is no way to differentiate stdout from stderr.

[ghost]

@cpuguy83
I've tested the containers logs with the following JS

const http = require('http');

http.get('http://127.0.0.1:8080/containers/d2cf357d5602918f3dfbd50e7a7f37f72788a42091eb46856e890329a2628877/logs?stdout=1&follow=1', (resp) => {
  let data = '';

  // A chunk of data has been recieved.
  resp.on('data', (chunk) => {
    data += chunk;
    console.log(data.toString('utf8'));
  });

  // The whole response has been received. Print out the result.
  resp.on('end', () => {
    console.log();
  });

}).on("error", (err) => {
  console.log("Error: " + err.message);
});
 

its work corretly since there no conn Hijack,
its confusing me to atttach ws to grab the containers/service logs
but différents users have différents use cases and i belive API should be able to honor this feature
eventually do we need to support ws ?

[cpuguy83]

I'm not saying that attach should grab the container or service logs.
I'm saying the attach ws endpoint is incorrect because it cannot differentiate between container i/o streams.

What I am saying is:

1. The service logs endpoint is not doing a hijack.
2. All the logs endpoints (and attach) really should be updated to support getting a single stream without having the mux headers.