[
https://issues.apache.org/jira/browse/HTTPCORE-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14511531#comment-14511531
]
Michael Osipov edited comment on HTTPCORE-400 at 4/24/15 6:55 PM:
------------------------------------------------------------------
While following this discussion, I am inclided to agree with Oleg, for at least
three reasons:
1. The Mono implementation is stupid. It compares on the toString
representation which is plain wrong, as far as i can see. Given that parameters
are order-insensitive, there will be not equal, although they are: {{bla=foo;
blub=bar}} and {{blub=bar; bla=foo}}.
2. JAX-RS' is a bit better by comparing real fields and not strings
3. JAX-RS uses toLowerCase in hasCode without Locale.ROOT. We all know that
this is a problem.
But still, the very meaning of {{Content-Type}} is only known to the server and
and its consumer. The transporting lib has no knowledge about it. At best,
{{ContentType}} could compare type and subtype. Not speaking of hash code at
all.
Why not extend ContentType by passing an optional comparator to the
constructor? This could be the set in HttpClientBuilder and passed to HttpCore.
Consumer would be in control of comparison. Of course, a HashCodeBuilder would
be necessary too.
Это серьёзная хуйня!
was (Author: michael-o):
While following this discussion, I am inclided to agree with Oleg, for at least
three reasons:
1. The Mono implementation is stupid. It compares on the toString
representation which is plain wrong, as far as i can see. Given that qualifiers
are order-insensitive, there will be not equal, although they are: {{bla=bar;
blub=bar}} and {{blub=bar; bla=bar}}.
2. JAX-RS' is a bit better by comparing real fields and not strings
3. JAX-RS uses toLowerCase in hasCode without Locale.ROOT. We all know that
this is a problem
but still, the very meaning of {{Content-Type}} is only known to the server and
and its consumer. The transporting lib has no knowledge about. At best,
{{ContentType}} could compare type and subtype. Not speaking of hash code at
all.
Why not extend ContentType by passing a optional comparator to the constructor?
This could the set in HttpClientBuilder and passed to HttpCore. Consumer would
be in control of comparsion. Of course a HashCodeBuilder would be necessary too.
> ContentType.equals & hashCode are not implemented
> -------------------------------------------------
>
> Key: HTTPCORE-400
> URL: https://issues.apache.org/jira/browse/HTTPCORE-400
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Reporter: Volodymyr Kyrychenko
>
> Since equals and hashCode are not implemented it's impossible to use them in
> handful of cases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
