On 30/03/18 12:22, ajs6f wrote: > For at least some cases, this wouldn't be good for security.
That is debatable. Providing exact version information is highly unlikely (I almost wrote impossible but never say never) to create a vulnerability. It might make a vulnerability more obvious but if the client is vulnerable, it is vulnerable whether or not the version information is provided. Trying to hide the version information (it may be exposed indirectly elsewhere) is security by obscurity which is no security at all. The key question for me is does the client OS or Java version matter? Why might this information be useful to a sever? I do have a privacy concern. As a user I may not wish to expose my choice of JRE or OS to the server. My default position would be not to send it at all. Depending on the answer to "How is this info useful?", I could be persuaded to support making it optional, possibly even present by default. Of course, all of this is from the peanut gallery as I haven't contributed to this component and am unlikely to do so any time soon. Mark > I would prefer that this be configurable (via HttpClientBuilder and/or system props) and not the default. > > ajs6f > >> On Mar 29, 2018, at 6:20 PM, Gary Gregory <[email protected]> wrote: >> >> Hi All: >> >> Right now, the HttpClient is of the form: >> >> User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_162) >> >> With the stack I am working with, it would be handy if the header reflected: >> >> - The Java vendor >> - Operating system name and version. >> >> For example: >> >> User-Agent: Apache-HttpClient/4.5.5 (Oracle Corporation/Java/1.8.0_162) >> Windows/10.0 (amd64) >> >> Any thoughts for or against adding this to the user agent string? >> >> Gary > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
