Hey Jose, Yes, we have considered it. Check "Put clientName and clientVersion in the RequestHeader" in the rejected alternatives.
Best, David On Tue, Sep 17, 2019 at 12:57 AM Jose Armando Garcia Sancio < jsan...@confluent.io> wrote: > On Mon, Sep 9, 2019 at 4:00 PM Colin McCabe <cmcc...@apache.org> wrote: > > > > > One solution to consider is adding the clientVersion and clientType to > the > > request header as optional (tagged) fields. This would let us skip the > > extra round trip. I don't think it's that much more messy than having a > > separate request type to set the client version and type. In both cases, > > you have to handle connections that set the version later than others, or > > don't set the version at all (for compatibility). So the version/type > has > > to be mutable and added after the TCP connection itself is established. > > > Hey David, > > Did we consider Colin's suggestion of adding this information to every > request using tagged field? If so can we add a section to the KIP > documenting the decision? > > The HTTP protocol solves a similar problem by using a special header called > User-Agent. In that field clients encode much more information than just > client version and type. For example Mozilla uses this to include platform > version and engine version. E.g. > > User-Agent: Mozilla/<version> (<system-information>) <platform> > (<platform-details>) <extensions> > > https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent > > Thanks! > > -Jose >
