Wrong implementation of convertHeaders in BasicNetwork

21 views
Skip to first unread message

Mate

unread,
Oct 14, 2016, 9:34:24 AM10/14/16
to Volley Users
Hi List :)

Im not sure where to file a volley bug, so maybe you can help.

I realized that the Volley BasicNetwork impletation has a bug handling Response Header.
As defined here in HTTP RFC2616 it is totaly fine to have multible header fields:

Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded

I realized this bug with multiple cache-control Headers like this:
Cache-Control:max-age=86400
Cache-Control:public

With the following implementation the Cache-Control:max-age=86400 header will be overwritten by the Cache-Control:public header and so Volley is not working correctly anymore.

/**
* Converts Headers[] to Map<String, String>.
*/
protected static Map<String, String> convertHeaders(Header[] headers) {
    Map<String, String> result = new TreeMap<String, String>(String.CASE_INSENSITIVE_ORDER);
    for (int i = 0; i < headers.length; i++) {
       result.put(headers[i].getName(), headers[i].getValue());
    }
    return result;
}


An easy fix could be to just look if the header is already set and if yes, append a comma and the next value.


Reply all
Reply to author
Forward
0 new messages