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.
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
>>
>
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109