Thanks! I seem to recall we made some changes in the content-type in the past that we had to revert as it broke some things. I'll have to dig into history for that though.

Perhaps it should perform content-negotiation, and depending on what the client advertises, use one or the other.

I also wondered about the potential impact changing the Content-type. Could probably only send this more relevant content type is client sends Accept header with explicit support for this mime type, wdyt?

Yes, I was thinking along those lines indeed. When doing so, I think there's some utility package that we already use somewhere to make sure we parse Accept headers correctly (as they can be hard to parse)

These responses were always a bit "hairy" because when we implemented them, it was not really an official RFC yet, so there was no official content-type (other than some conventions used by some).

Ah, yes, this was the one;

That same packages also has a NegotiateContentType() function. Not sure if it's the best package (but it's "somewhat" official), but at least good to stick to one implementation.

(that code was part of the godoc.org code, and has now been archived; not a major concern, but perhaps we need to look if it's maintained elsewhere as well, but we can look at that later)

IIUC Kubernetes uses bitbucket.org/ww/goautoneg, so seems a reasonable dependency to be added to align with other projects in our ecosystem, wdyt?

Thanks! So ... it looks like the bitbucket.org/ww/goautoneg package went AWOL, and they switch to a fork of it in kubernetes/kubernetes@16fd72d (switching to https://github.com/munnerz/goautoneg).

What slightly concerns me is that it feels a bit like they "just picked a fork of the original one", which is in a personal repository (not an org) and the owner apparently just made a fork, but is not a real expert on the code itself munnerz/goautoneg#3 (review)

This seems good to me, although I'm not too well-versed in this code.

Not saying we shouldn't switch to that package, but based on the above, I think it'd be good to have a good look how the implementation differs from what' we're currently using (if it's considerably better) before deciding whether or not we should switch. We could continue to use the current implementation (for now), and look for a possible replacement in a follow-up.

oh ok, I didn't checked the status of this dependency, makes perfect sense to keep our current implementation then, until the other ones demonstrates to be somehow a better one (?). Thanks for digging into this

Thanks! We briefly went through this PR in the maintainers meeting, and we're good with this change in general.

I want to have another look, to look more into detail, but from an earlier glance (some of this could be in a follow-up);

• the swagger now only documents the new content-type as "produces" (I think it's possible to document both content-types separately, but I need to double check how swagger expects "content-negotiation" to be mentioned)
• there may be other endpoints that use the same "json-progress" output; we should probably make them all do the same (could be in a follow-up)
• we should check if the client code needs to be updated (i.e., make sure the client sends Accepts header for both application/json and the new content-type, so that it can talk with both "old" and "new" engines, and that new engines actually return the new content-type)

swagger doesn't offer an explicit way to declare content-negotiation, but allows to define multiple values for produced content that a consumer can use to define Accept header for preferred format.
I've identified /events as another producer for json sequence.
Would be easy to add more in a follow-up pull-request in cased we missed one.

Doesn't application/json-seq / RFC 7464 technically suggest the use of a "Record Separator" byte between JSON documents in addition to line-feed? Aren't our APIs only using line-feed?

(Also, I'm not sure it matters technically, but the two swagger changes here appear to use different orderings in produces: that I think should probably be consistent.)

@tianon correct. I need to check how we can get streamformatter.progressOutput to not only append LF after progress messages but also prepend RS.

Ah! Forgot to respond; good catch, @tianon (that one time I didn't dive into the RFC 😬 😂).

Let me know if you need help, @ndeloof ! (although I'm not super familiar with the streamformatter either 😂)

Before I forget; now that this PR needs updating, can you also add a note to the API history, and mention the new content-types / response types for these endpoints? https://github.com/moby/moby/blob/master/docs/api/version-history.md

Closing as obsolete