A couple of checks may be added to DigestAuthentication class.

1. DigestAuthentication.setNonce(String) method doesn't check its parameter for null:

http://hg.openjdk.java.net/jdk9/dev/jdk/file/4204dbf90380/src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java#l165

...
        synchronized void setNonce (String s) {
            if (!s.equals(nonce)) {
                nonce=s;
                NCcount = 0;
                redoCachedHA1 = true;
            }
        }
...

As a result, an NPE may occur here. This may happen if a buggy HTTP server returns "WWW-Authenticate" header which doesn't contain a "nonce" field. According to RFCs 2069 [1] and 2617 [2], this is not expected behavior of server, but it would be better if an HTTP client threw a checked IOException instead of NPE.

2. RFC 2617 [2] says the following about "qop" field in "WWW-Authenticate" header:

...
qop-options
     This directive is optional, but is made so only for backward
     compatibility with RFC 2069 [6]; it SHOULD be used by all
     implementations compliant with this version of the Digest scheme.
     If present, it is a quoted string of one or more tokens indicating
     the "quality of protection" values supported by the server. The
     value "auth" indicates authentication; the value "auth-int"
     indicates authentication with integrity protection; see the
     descriptions below for calculating the response directive value for
     the application of this choice. Unrecognized options MUST be
     ignored.
...

It says that "qop" may contain more than one token, but it doesn't specify a delimiter for "qop" field in "WWW-Authenticate" header. There is an example of "WWW-Authenticate" header in RFC 2617 [2] where a comma is used as a delimiter of value in "qop" field:

...
    WWW-Authenticate: Digest
                 realm="testrealm@host.com",
                 qop="auth,auth-int",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"
...

DigestAuthentication.setQop(String) method uses only a whitespace as a delimiter:

http://hg.openjdk.java.net/jdk9/dev/jdk/file/4204dbf90380/src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java#l147

...
        synchronized void setQop (String qop) {
            if (qop != null) {
                StringTokenizer st = new StringTokenizer (qop, " ");
                while (st.hasMoreTokens()) {
                    if (st.nextToken().equalsIgnoreCase ("auth")) {
                        serverQop = true;
                        return;
                    }
                }
            }
            serverQop = false;
        }
...

If an HTTP server use a comma as a delimiter, then "qop" field will be ignored. As a result, a client nonce will not be used during validation of "Authentication-Info" header:

http://hg.openjdk.java.net/jdk9/dev/jdk/file/4204dbf90380/src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java#l497

...
if (params.authQop()) { /* RRC2617 when qop=auth */
            combo = HashA1+ ":" + nonceString + ":" + ncValue + ":" +
                        cnonce + ":auth:" +HashA2;
...

It may be better to make DigestAuthentication accept both a whitespace and a comma as a delimiter.

The issue above may be fixes with the following patch:

http://cr.openjdk.java.net/~asmotrak/http_auth_digest/webrev.00/

The webrev above also contain several testcase for HTTP Digest authentication (I didn't find test for it in jdk/test).

[1] https://tools.ietf.org/html/rfc2069
[2] https://tools.ietf.org/html/rfc2617