Paul Sandoz wrote:
> Reto Bachmann-Gmür wrote:
>> Hi Paul
>>
>> I think specifying that the keys are all-lower case in the map and
>> have HttpHeaders.getRequestHeader(name) return
>> map.get(name.toLowerCase()) would be enough.
>
> From an ease of use perspective having the developer lower-case the
> header name or utilize a case insensitive string class is taking a step
> backwards. Such a regression is not worth it for edge case comparison of
> map and map entry set equality that will not achieve, semantically,
> correct equality of header values.
I'm not suggesting that the user should do anything, at least not as
long as they acces the values using HttpHeaders.getRequestHeader. The
lower cases is the internal storage of the map and the values returned
by map.keySet() etc.
I think independently on how often a feature is used, if we extend Map
we must comply with the specification of Map.
Reto
>
> Paul.
>
>> Furthermore the constants in HttpHeaders could be adapted to have
>> lower-case value.
>>
>> Imho, the better solution would be to have a case-insensitive String
>> class used as key. This class would define that toString() returns its
>> value, that equals returns true iff the strings are equlas ignoring
>> case and that the hashcode if e.g. the hashcode of the lower-case
>> representation of the string.
>>
>> Cheers,
>> Reto
>>
>>
>> Paul Sandoz wrote:
>>> Hi Reto,
>>>
>>> I think you have found a very edgy case :-) The reason being is
>>> header value equality for many HTTP headers is not equal to the
>>> string equality. Thus it is unlikely that such map equality will do
>>> what is really required.
>>>
>>> Bill, i think the issue is when a type compatible map, such as
>>> HashMap<String, List<String>> is compared with the map returned by
>>> the getRequestHeaders. Equality of two maps returned by
>>> getRequestHeaders could be supported.
>>>
>>> It is possible to support case-insensitive look up, i.e. not
>>> mandating that a developer convert to upper or lower case, and
>>> equality to other type equivalent maps if we mandate, as you point
>>> out, that keys are always lower cased. Thus a developer using another
>>> type equivalent map is required to put keys in lower case.
>>>
>>> Given that we are just a couple of days away from making the final
>>> cut to the API it is important to minimize the changes (if any) we
>>> make to resolve this edge case.
>>>
>>> Paul.
>>>
>>> On Sep 1, 2008, at 12:11 PM, Reto Bachmann-Gmür wrote:
>>>
>>>> HttpHeaders.getRequestHeaders has to return a
>>>> MultivaluedMap<java.lang.String,java.lang.String> that is
>>>> case-insensitive with regards to keys. I'm not sure how such a case
>>>> insensitive map is supposed to work exactly (e.g. what does keySet
>>>> return?) and I think that it might be quite hard to have a
>>>> definition compatible the the API for the java.util.Map (which is
>>>> extended by MultivaluedMap).
>>>>
>>>> An issue is map identity. The javadoc for java.util.Map.equals says:
>>>> "Returns true if the given object is also a map and the two maps
>>>> represent the same mappings." as the mapping of keys with different
>>>> casing is the same I would think that two maps are equals is they
>>>> differ only by the casing of the keys, however the text more
>>>> specifically says: "More formally, two maps m1 and m2 represent the
>>>> same mappings if m1.entrySet().equals(m2.entrySet())." The latter
>>>> condition is only met if the EntryS contains the key with the same
>>>> casing (or if the keyset is expanded to contain possible casings of
>>>> a key), but this is not defined by the jax-rs spec.
>>>>
>>>> I think jax-rs should not introduce a case-insensitive map but
>>>> rather either specify that all-lower (or upper) case strings are to
>>>> be used as keys or introduce a class like "CaseInsensitiveString"
>>>> used as key in the map.
>>>>
>>>> Reto
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
>>> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>>>
>>
>>
>