Rectangle 27 0

android java.io.IOException : No authentication challenges found?


HttpURLConnection connection = ...;
try {
    // Will throw IOException if server responds with 401.
    connection.getResponseCode(); 
} catch (IOException e) {
    // Will return 401, because now connection has the correct internal state.
    int responsecode = connection.getResponseCode(); 
}
  • Add a fake "WWW-Authenticate" header like: WWW-Authenticate: Basic realm="fake". This is a mere workaround not a solution, but it should work and the http client is satisfied (see here a discussion for what you can put in the header). But beware that some http clients may automatically retry the request resulting in multiple requests (e.g. increments wrong login count too often). This was observed with the ios http client.
  • Use HTTP status code 403 instead of 401. It's semantic is not the same and usually when working with login 401 is a correct response (see here for detailed discussion) but the safer solution in terms of compatibility.

(...)The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource.(...)

As @ErikZ wrote in his post you could use a try&catch

Cool man, I swear I saw a different behavior, anyway just tested what you are saying and is correct +1...

I'm having this problem on one Android device but not another, I guess some OEMs overwrite the HttpUrlConnection class? Either way, this fix worked.

Possible solutions if you can change the server:

Possible solutions if you can't change the server:

This error happens beause the server sends a 401 (Unauthorized) but does not give a WWW-Authenticate header which is a hint for the client what to do next. The WWW-Authenticate header tells the client which kind of authentication is needed (either Basic or Digest). This is probably not very useful in headless http clients, but thats how the HTTP 1.1 RFC is defined. The error occurs because the lib tries to parse the WWW-Authenticate header but can't.

You are a god among men.

Note
Rectangle 27 0

android java.io.IOException : No authentication challenges found?


urlConnection.setRequestProperty("Authorization", "Basic " + Base64.encodeToString("userid:pwd".getBytes(), Base64.NO_WRAP ));

1) in my code, I removed the authenticator (I didn't try combinations of it and setRequestProperty) 2) for the setRequestProperty above, NO_WRAP was definitely necessary since removing it caused a failure 3) Sorry. I'm developing on Windows. I don't know what Mac tools exist.

I had difficulties with the Android authenticator during some development work on Gingerbread (I don't know if it behaves differently on later versions of Android). I used Fiddler2 to examine the HTTP traffic between my app and the server, discovering that the authenticator did not send out the authentication string for every HTTP request. I needed it to.

I have tried this. But did not work. Even I have tried using different base64 flags like URL_SAFE, NO_WRAP, DEFAULT. I also tried "URL_SAFE | NO_WRAP".

It's a cut-and-paste from my code. Note that urlConnection is an HttpURLConnection object.

What version of Android are you testing on?

Note
Rectangle 27 0

android java.io.IOException : No authentication challenges found?


HttpURLConnection connection = ...;
try {
    // Will throw IOException if server responds with 401.
    connection.getResponseCode(); 
} catch (IOException e) {
    // Will return 401, because now connection has the correct internal state.
    int responsecode = connection.getResponseCode(); 
}
  • Add a fake "WWW-Authenticate" header like: WWW-Authenticate: Basic realm="fake". This is a mere workaround not a solution, but it should work and the http client is satisfied (see here a discussion for what you can put in the header). But beware that some http clients may automatically retry the request resulting in multiple requests (e.g. increments wrong login count too often). This was observed with the ios http client.
  • As proposed by loudvchar in this blog to avoid automatic reactions to the challenge like a pop-up login form in a browser, you can use a non-standard authentication method like so: WWW-Authenticate: xBasic realm="fake". The important point is that the realm has to be included.
  • Use HTTP status code 403 instead of 401. It's semantic is not the same and usually when working with login 401 is a correct response (see here for detailed discussion) but the safer solution in terms of compatibility.

(...)The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource.(...)

As @ErikZ wrote in his post you could use a try&catch

Cool man, I swear I saw a different behavior, anyway just tested what you are saying and is correct +1...

I'm having this problem on one Android device but not another, I guess some OEMs overwrite the HttpUrlConnection class? Either way, this fix worked.

Possible solutions if you can change the server:

Possible solutions if you can't change the server:

This error happens beause the server sends a 401 (Unauthorized) but does not give a WWW-Authenticate header which is a hint for the client what to do next. The WWW-Authenticate header tells the client which kind of authentication is needed (either Basic or Digest). This is probably not very useful in headless http clients, but thats how the HTTP 1.1 RFC is defined. The error occurs because the lib tries to parse the WWW-Authenticate header but can't.

You are a god among men.

Note
Rectangle 27 0

android java.io.IOException : No authentication challenges found?


urlConnection.setRequestProperty("Authorization", "Basic " + Base64.encodeToString("userid:pwd".getBytes(), Base64.NO_WRAP ));

1) in my code, I removed the authenticator (I didn't try combinations of it and setRequestProperty) 2) for the setRequestProperty above, NO_WRAP was definitely necessary since removing it caused a failure 3) Sorry. I'm developing on Windows. I don't know what Mac tools exist.

I had difficulties with the Android authenticator during some development work on Gingerbread (I don't know if it behaves differently on later versions of Android). I used Fiddler2 to examine the HTTP traffic between my app and the server, discovering that the authenticator did not send out the authentication string for every HTTP request. I needed it to.

I have tried this. But did not work. Even I have tried using different base64 flags like URL_SAFE, NO_WRAP, DEFAULT. I also tried "URL_SAFE | NO_WRAP".

It's a cut-and-paste from my code. Note that urlConnection is an HttpURLConnection object.

What version of Android are you testing on?

Note
Rectangle 27 0

android java.io.IOException : No authentication challenges found?


  • Add a fake "WWW-Authenticate" header like: WWW-Authenticate: Basic realm="fake". This is a mere workaround not a solution, but it should work and the http client is satisfied (see here a discussion of what you can put in the header). But beware that some http clients may automatically retry the request resulting in multiple requests (e.g. increments the wrong login count too often). This was observed with the iOS http client.
  • As @ErikZ wrote in his post you could use a try&catch HttpURLConnection connection = ...; try { // Will throw IOException if server responds with 401. connection.getResponseCode(); } catch (IOException e) { // Will return 401, because now connection has the correct internal state. int responsecode = connection.getResponseCode(); }
  • As proposed by loudvchar in this blog to avoid automatic reactions to the challenge like a pop-up login form in a browser, you can use a non-standard authentication method like so: WWW-Authenticate: xBasic realm="fake". The important point is that the realm has to be included.
  • Use HTTP status code 403 instead of 401. It's semantic is not the same and usually when working with login 401 is a correct response (see here for a detailed discussion) but the safer solution in terms of compatibility.

(...)The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource.(...)

Cool man, I swear I saw a different behavior, anyway just tested what you are saying and is correct +1...

I'm having this problem on one Android device but not another, I guess some OEMs overwrite the HttpUrlConnection class? Either way, this fix worked.

Possible solutions if you can change the server:

Possible solutions if you can't change the server:

This error happens because the server sends a 401 (Unauthorized) but does not give a WWW-Authenticate header which is a hint to the client what to do next. The WWW-Authenticate header tells the client, which kind of authentication is needed (either Basic or Digest). This is probably not very useful in headless http clients, but that's how the HTTP 1.1 RFC is defined. The error occurs because the lib tries to parse the WWW-Authenticate header but can't.

You are a god among men.

Note
Rectangle 27 0

android java.io.IOException : No authentication challenges found?


HurlStack hurlStack = new HurlStack() {
            @Override
            public HttpResponse performRequest(final Request<?> request, final Map<String, String> additionalHeaders) throws IOException, AuthFailureError {
                try {
                    return super.performRequest(request, additionalHeaders);
                } catch (IOException e) {
                    return new BasicHttpResponse(new ProtocolVersion("HTTP", 1, 1), 401, e.getMessage());
                }
            }
        };

Volley.newRequestQueue(context.getApplicationContext(), hurlStack);

I had the same issue on devices running pre-KitKat Android, but I was using the Volley library so the client side fix provided by @for3st didn't work for me, I had to adjust it for Volley, here it is, hope it helps someone struggling with this problem:

This way a 401 error is returned and your retry policy can do it's job (e.g. request token... etc...). Although IOException could be caused by some other problem, other then a 401, so you could opt for parsing the exception message for Authorization keyword, and return a different response code for others.

Note
Rectangle 27 0

android java.io.IOException : No authentication challenges found?


urlConnection.setRequestProperty("Authorization", "Basic " + Base64.encodeToString("userid:pwd".getBytes(), Base64.NO_WRAP ));

1) in my code, I removed the authenticator (I didn't try combinations of it and setRequestProperty) 2) for the setRequestProperty above, NO_WRAP was definitely necessary since removing it caused a failure 3) Sorry. I'm developing on Windows. I don't know what Mac tools exist.

I had difficulties with the Android authenticator during some development work on Gingerbread (I don't know if it behaves differently on later versions of Android). I used Fiddler2 to examine the HTTP traffic between my app and the server, discovering that the authenticator did not send out the authentication string for every HTTP request. I needed it to.

I have tried this. But did not work. Even I have tried using different base64 flags like URL_SAFE, NO_WRAP, DEFAULT. I also tried "URL_SAFE | NO_WRAP".

It's a cut-and-paste from my code. Note that urlConnection is an HttpURLConnection object.

What version of Android are you testing on?

Note
Rectangle 27 0

android java.io.IOException : No authentication challenges found?


  • Add a fake "WWW-Authenticate" header like: WWW-Authenticate: Basic realm="fake". This is a mere workaround not a solution, but it should work and the http client is satisfied (see here a discussion of what you can put in the header). But beware that some http clients may automatically retry the request resulting in multiple requests (e.g. increments the wrong login count too often). This was observed with the iOS http client.
  • As @ErikZ wrote in his post you could use a try&catch HttpURLConnection connection = ...; try { // Will throw IOException if server responds with 401. connection.getResponseCode(); } catch (IOException e) { // Will return 401, because now connection has the correct internal state. int responsecode = connection.getResponseCode(); }
  • As proposed by loudvchar in this blog to avoid automatic reactions to the challenge like a pop-up login form in a browser, you can use a non-standard authentication method like so: WWW-Authenticate: xBasic realm="fake". The important point is that the realm has to be included.
  • Use HTTP status code 403 instead of 401. It's semantic is not the same and usually when working with login 401 is a correct response (see here for a detailed discussion) but the safer solution in terms of compatibility.

(...)The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource.(...)

Cool man, I swear I saw a different behavior, anyway just tested what you are saying and is correct +1...

I'm having this problem on one Android device but not another, I guess some OEMs overwrite the HttpUrlConnection class? Either way, this fix worked.

Possible solutions if you can change the server:

Possible solutions if you can't change the server:

This error happens because the server sends a 401 (Unauthorized) but does not give a WWW-Authenticate header which is a hint to the client what to do next. The WWW-Authenticate header tells the client, which kind of authentication is needed (either Basic or Digest). This is probably not very useful in headless http clients, but that's how the HTTP 1.1 RFC is defined. The error occurs because the lib tries to parse the WWW-Authenticate header but can't.

You are a god among men.

Note
Rectangle 27 0

android java.io.IOException : No authentication challenges found?


compile 'com.squareup.okhttp:okhttp:2.5.0'
compile 'com.squareup.okhttp:okhttp-urlconnection:2.5.0'

Had the same issue on some old devices (Huawei Y330-U11 for instance). Correct way to fix it is to fix it server side as mentioned in the most popular answer.

However, it's really disappointing that the issue occurs only on some devices. And I believe it happens due to different implementations of "UrlConnection". Different Android versions - different "UrlConnection" implementations.

It solved the problem for me on those outdated devices. (I had to use OkClient for Retrofit RestAdapter)

So, you might want to fix it by using the same "UrlConnection" everywhere. Try to use okhttp and okhttp-urlconnection.

Note
Rectangle 27 0

android java.io.IOException : No authentication challenges found?


compile 'com.squareup.okhttp:okhttp:2.5.0'
compile 'com.squareup.okhttp:okhttp-urlconnection:2.5.0'

Had the same issue on some old devices (Huawei Y330-U11 for instance). Correct way to fix it is to fix it server side as mentioned in the most popular answer.

However, it's really disappointing that the issue occurs only on some devices. And I believe it happens due to different implementations of "UrlConnection". Different Android versions - different "UrlConnection" implementations.

It solved the problem for me on those outdated devices. (I had to use OkClient for Retrofit RestAdapter)

So, you might want to fix it by using the same "UrlConnection" everywhere. Try to use okhttp and okhttp-urlconnection.

Note