Adding SocketChannel toString to connection exception messages
chris.hegarty at oracle.com
Fri Dec 22 09:57:48 UTC 2017
On 22/12/17 01:27, David Holmes wrote:
> cc'ing net-dev as that might be the more appropriate list.
> On 22/12/2017 10:59 AM, Steven Schlansker wrote:
>>> On Dec 21, 2017, at 4:35 PM, David Holmes <david.holmes at oracle.com>
>>> On 22/12/2017 10:29 AM, Steven Schlansker wrote:
>>>>> On Dec 21, 2017, at 11:11 AM, Steven Schlansker
>>>>> <stevenschlansker at gmail.com> wrote:
>>>>> What if ConnectException included the attempted hostname / IP /
>>>>> port SocketAddress?
>>>>> java.net.ConnectException: Connection to
>>>>> 'foo.mycorp.com[10.x.x.x]:12345' refused
>>>>> Much more useful! This could also be extended to various other
>>>>> socket exceptions.
>>> I believe there are concerns with too much information that can be
>>> considered "sensitive" (like host names and IP addresses) appearing
>>> in error messages due to them ending up in log files and bug reports.
>> Unfortunately that's exactly the information that is crucial to
>> someone trying to diagnose issues...
And to someone trying to discern private information about a network.
>> Could it be an opt-in policy? Perhaps by a system property?
Well, you don't know where a log file or exception will end up.
Most likely on stackoverflow.
> The expectation is that such information should be added by layers
> higher in the call chain, rather than the JDK libraries assuming it is
> okay to do.
Agreed. It may be some work, but if the issue is significant
enough to the user then it may be worth their effort, as well
as affording the opportunity to opt-out at any particular
point in the code.
>> Currently the alternative I'm faced with is going through every piece
>> of user code and library that *might*
>> throw this exception and wrapping it to add this critical diagnostic
>> information. For an application that uses
>> java.net heavily, you can imagine how that is a tall task and possibly
>> even not realistically achievable...
>> (Is there a written policy regarding this somewhere, or is it up to
>> the personal feelings of the contributors?)
> This is covered by the secure coding guidelines, under 'Confidential
> "Guideline 2-1 / CONFIDENTIAL-1: Purge sensitive information from
> I know for a fact that we'd have to scrub this information from test
> failures when putting the info into a bug report.
> If net-dev folk can't expand further on this then I suggest filing a CSR
> request so that the CSR group can consider it. But I think this will be
> a no-go (I'm a member of the CSR group).
I have to agree with David here. I don't think that such a request
could be supported.
More information about the core-libs-dev