Trying to think what's the best way to implement this; currently this change is not versioned, and the daemon doesn't return an error if a new client would try to get this media-type on an older daemon, in which case it silently falls back to application/json, even if that's not included in the client's list of accepted content-types;

curl -v -H 'Accept: application/jsonl' --unix-socket /var/run/docker.sock http://localhost/v1.52/
events
*   Trying /var/run/docker.sock:0...
* Connected to localhost (/var/run/docker.sock) port 0
* using HTTP/1.x
> GET /v1.52/events HTTP/1.1
> Host: localhost
> User-Agent: curl/8.14.1
> Accept: application/jsonl
>
* Request completely sent off
< HTTP/1.1 200 OK
< Api-Version: 1.52
< Content-Type: application/json
< Date: Mon, 08 Dec 2025 12:38:50 GMT
< Docker-Experimental: false
< Ostype: linux
< Server: Docker/29.1.1 (linux)
< Transfer-Encoding: chunked

Of course, in practice, the response itself should still be fine, but it won't return the expected content-type :thinking_face:

@thaJeztah engine does not check Accept header in any place, so I don't expect any client to expect a strict behavior:

curl --unix-socket /var/run/docker.sock -v -H 'Accept: application/xml' http://lcoalhost/containers/json
*   Trying /var/run/docker.sock:0...
* Connected to lcoalhost (/var/run/docker.sock) port 0
> GET /containers/json HTTP/1.1
> Host: lcoalhost
> User-Agent: curl/8.7.1
> Accept: application/xml
> 
* Request completely sent off
< HTTP/1.1 200 OK
< Api-Version: 1.52
< Content-Type: application/json

As long as response's Content-Type is correct, client should be able to parse with the adequate logic

Derp; missed your comment

Yeah, the Go client doesn't check the response type and just considers them all equal (which they "roughly" are). I was wondering if other clients would check the response type to handle (e.g.) application/json-seq different than application/x-ndjson (or application/jsonl). If such a client would only send application/jsonl as "accept" header, and the daemon would return a different content-type as requested, that would be potentially unexpected.

I seemed to recall that the correct response was a 406 or a 300, but there's been quite some different descriptions throughout specs, and I just found that MDN (which is not the specification, but usually contains useful information) mentions; https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/406

A server may return responses that differ from the request's accept headers. In such cases, a 200 response with a default resource that doesn't match the client's list of acceptable content negotiation values may be preferable to sending a 406 response.

So, yeah, looks like returning a 200 is not uncommon, so probably OK; perhaps we should add a code-comment that links to that page and a short blurb documenting that we've chosen to use 200 instead of 406?