Volley解析--BUG 之status code 问题

google i/o上的推出的volley框架 确实是很不错的，在使用的过程中也是很好扩展的，最近在做restful api时遇到问题，当服务器发送的响应头 低于200 大于299时就会异常，其实这是个bug ，在BasicNetwork 117行

                if (statusCode < 200 || statusCode > 299) {
                    throw new IOException();
                }

然后volley捕获异常

   catch (IOException e) {
                int statusCode = 0;
                NetworkResponse networkResponse = null;
                if (httpResponse != null) {
                    statusCode = httpResponse.getStatusLine().getStatusCode();
                } else {
                    throw new NoConnectionError(e);
                }
                VolleyLog.e("Unexpected response code %d for %s", statusCode, request.getUrl());
                if (responseContents != null) {
                    networkResponse = new NetworkResponse(statusCode, responseContents,
                            responseHeaders, false);
                    if (statusCode == HttpStatus.SC_UNAUTHORIZED ||
                            statusCode == HttpStatus.SC_FORBIDDEN) {
                        attemptRetryOnException("auth",
                                request, new AuthFailureError(networkResponse));
                    } else {
                        // TODO: Only throw ServerError for 5xx status codes.
                        throw new ServerError(networkResponse);
                    }
                } else {
                    throw new NetworkError(networkResponse);
                }
            }

也了解了一些解决办法 没有找到合适，

有说，修改服务器返回的状态码，有说自定义request  然后获取状态码再处理  这些请在stackoverflow自己搜索吧，喔感觉吧没什么用，毕竟有时候就是需要 这个状态码 做些操作，所以 我们需要自定义自己的Network，具体参考下文。

搜集的解决方法1：

public class GsonRequest<T> extends Request<T> {

    ...
    private int mStatusCode;

    public int getStatusCode() {
        return mStatusCode;
    }
    ...

    @Override
    protected Response<T> parseNetworkResponse(NetworkResponse response) {

        mStatusCode = response.statusCode;
        try {
            Log.d(TAG, "[raw json]: " + (new String(response.data)));
            Gson gson = new Gson();
            String json = new String(response.data, HttpHeaderParser.parseCharset(response.headers));
            return Response.success(gson.fromJson(json, mClazz),
                HttpHeaderParser.parseCacheHeaders(response));

        } catch (UnsupportedEncodingException e) {
            return Response.error(new ParseError(e));
        } catch (JsonSyntaxException e) {
            return Response.error(new ParseError(e));
        }
    }
    ...
}

public class myClazz extends FragmentActivity {


    private Request mMyRequest;
    ...

    public void makeNetworkCall() {
    mMyRequest = new MyNetworkRequest(
            Method.GET, 
            BASE_URL + Endpoint.USER,
            new Listener<String>() {

                @Override
                public void onResponse(String response) {
                    // Success

                }
            }, 
            new ErrorListener() {

                @Override
                public void onErrorResponse(VolleyError error) {
                    if (mMyRequest.getStatusCode() == 401) {
                        // HTTP Status Code: 401 Unauthorized
                    }
                }
            });

    MyVolley.getRequestQueue().add(request);
}

 401 Not Supported by Volley

It turns out that it is impossible to guarantee that error.networkResponse is non-null without modifying Google Volley code because of a bug in Volley that throws the Exception NoConnectionError for Http Status Code 401 (HttpStatus.SC_UNAUTHORIZED) in BasicNetwork.java (134) prior to setting the value of networkResponse.

Work-Around

Instead of fixing the Volley code, our solution in this case was to modify the Web Service API to send Http Error Code 403 (HttpStatus.SC_FORBIDDEN) for the particular case in question.

 

For this Http Status Code, the value of error.networkResponse is non-null in the Volley error handler: public void onErrorResponse(VolleyError error). And, error.networkResponse.httpStatusCode correctly returns HttpStatus.SC_FORBIDDEN.

Other-Suggestions

Rperryng's suggestion of extending the Request<T> class may have provided a solution, and is a creative and excellent idea. Thank you very much for the detailed example. I found the optimal solution for our case is to use the work-around because we are fortunate enough to have control of the web services API.

 

I might opt for fixing the Volley code in one location within BasicNetwork.java if I did not have access to making a simple change at the server.