ProxyOptions setNonProxyHosts ability to support regex restricted by 18156

[jasonparallel]

Prior to #18156 setNonProxyHosts could support any regex. After 18156 only wildcards and only at the start or end are supported.

The java doc on setNonProxyHosts stayed the same before and after this change
Individual host strings may contain regex characters such as {@code '*'}.

It seems like the javadoc should reflect this reduction in the accepted input.

It would also be great if the old functionality was restored to allow a generic regex to be supplied perhaps via setNonProxyHostsRegex

[joshfree]

@alzimmermsft could you please take a look?

[alzimmermsft]

@jasonparallel, yes this would be a great idea to re-introduce full regex support for nonProxyHosts.

Do you have any example regexes you'll be using that I can add them as part of testing?

[jasonparallel]

@alzimmermsft We have a user defined regex of what to proxy so we have to wrap it in a negative look around when interacting with the sdk/netty.

Is the SDK doing the determination or just passing the regex into netty to let it do the determination?

[alzimmermsft]

Is the SDK doing the determination or just passing the regex into netty to let it do the determination?

Depends on the configuration of the proxy. If the proxy is authenticated we handle determination but otherwise it is passed along to Netty.

A quick fix to this would be attempting to Pattern.compile the nonProxyHosts string, if that passes use it as the regex to determine pass-through but if not fallback to the more restrictive handling. For reference the handling being done now aligns with the JDK default and what Reactor Netty does.