You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Richard Wise <ri...@googlemail.com.INVALID> on 2019/11/15 01:57:20 UTC

BasicHeader equality proposal

Hello,

I have read through the discussions about how BasicHeader.equals should be
implemented in https://issues.apache.org/jira/browse/HTTPCORE-499 and would
respectfully like to reopen this topic as currently I have to define test
helpers to compare two BasicHeaders due to the current equals method not
overriding Object.equals (my motivation for opening
https://issues.apache.org/jira/browse/HTTPCORE-610).

From my understanding of this discussion in HTTPCORE-499, it was proposed
to make BasicHeader implement equality by comparing the header name and
value. However, due to the complexities of dealing with white space and the
specifics of the Content-Type header value (MediaTypes), it was determined
that it would be too complicated to implement equality and therefore the
change was rolled back.

I would therefore like to propose an implementation of equals that would
allow semantic equality of headers that addresses the issues previously
raised.

Specifically, I propose that BasicHeader equality is defined where the
header name is compared via string-insensitive equality (to match the HTTP
header spec "Field names are case-insensitive" defined in
https://tools.ietf.org/html/rfc2616#section-4.2) and the value is compared
via string case- and whitespace-sensitive equality after stripping linear
leading or trailing whitespace (as the specification says that "Such
leading or trailing LWS MAY be removed without changing the semantics of
the field value") and separating values by commas (as per the spec
"...header field is defined as a comma-separated list"). For comparison of
MediaTypes, I suggest this be implemented in a separate method
(specifically MediaType.equals, based on the spec
https://tools.ietf.org/html/rfc7231#section-3.1.1.1) and used by
BasicHeader equality if the header is "Content-Type".

I believe that this change will improve the usability of this library and
help myself and others that are having to work around this omission (e.g.
https://issues.apache.org/jira/browse/HTTPCORE-439?focusedCommentId=16098536&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16098536
).

Thoughts?

Cheers,

Richard Wise

Re: BasicHeader equality proposal

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2019-11-15 at 09:57 +0800, Richard Wise wrote:
> Hello,
> 
> I have read through the discussions about how BasicHeader.equals
> should be
> implemented in https://issues.apache.org/jira/browse/HTTPCORE-499 and
> would
> respectfully like to reopen this topic as currently I have to define
> test
> helpers to compare two BasicHeaders due to the current equals method
> not
> overriding Object.equals (my motivation for opening
> https://issues.apache.org/jira/browse/HTTPCORE-610).
> 
> From my understanding of this discussion in HTTPCORE-499, it was
> proposed
> to make BasicHeader implement equality by comparing the header name
> and
> value. However, due to the complexities of dealing with white space
> and the
> specifics of the Content-Type header value (MediaTypes), it was
> determined
> that it would be too complicated to implement equality and therefore
> the
> change was rolled back.
> 
> I would therefore like to propose an implementation of equals that
> would
> allow semantic equality of headers that addresses the issues
> previously
> raised.
> 
> Specifically, I propose that BasicHeader equality is defined where
> the
> header name is compared via string-insensitive equality (to match the
> HTTP
> header spec "Field names are case-insensitive" defined in
> https://tools.ietf.org/html/rfc2616#section-4.2) and the value is
> compared
> via string case- and whitespace-sensitive equality after stripping
> linear
> leading or trailing whitespace (as the specification says that "Such
> leading or trailing LWS MAY be removed without changing the semantics
> of
> the field value") and separating values by commas (as per the spec
> "...header field is defined as a comma-separated list"). For
> comparison of
> MediaTypes, I suggest this be implemented in a separate method
> (specifically MediaType.equals, based on the spec
> https://tools.ietf.org/html/rfc7231#section-3.1.1.1) and used by
> BasicHeader equality if the header is "Content-Type".
> 
> I believe that this change will improve the usability of this library
> and
> help myself and others that are having to work around this omission
> (e.g.
> 
https://issues.apache.org/jira/browse/HTTPCORE-439?focusedCommentId=16098536&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16098536
> ).
> 
> Thoughts?
> 

It is not just complex, it is impossible. It is not possible to define
equality criteria that fit all type of headers in all cases, hence my
strong objection to having #equalsTo and #hashCode that are basically
wrong.

As I said before on many occasions I am however open to adding #isSame
or #isEqual (or some such) to BasicHeader and ContentType classes if
anyone cares to provide them.

Oleg



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org