Url hash values have changed between 0.2.34 and 0.2.35 about rust-url HOT 5 CLOSED

Ah, commit 3d4430b / issue #113.

Wouldn't you consider this a backwards incompatible change? I'd be pretty nervous if two rust programs could miscommunicate url hashes (e.g. via network or via serialisation) just because they have a single patch version difference in a dependency.

from rust-url.

I don’t know, are hash values significant? I’ve always thought of them as only meaningful for comparison with each other within one execution of a program and had not considered they could be relied on in anything serialized. Are they guaranteed to be the same on architectures? (Bit depth, endianness, etc.)

from rust-url.

Interesting question.

Scenario: a bunch of website-hitting applications (let's say they're all written in rust) which contact a central caching server before actually making their requests. You need to choose a suitable cache key.

My personal expectation would be that using a hash would be acceptable, since that's what hashmaps do. I'd (unthinkingly) expect this to work consistently for all minor/patch variations on library versions, and across different architectures.

However, reading the documentation of the Hash trait gives no hints about whether this is expected or not. Perhaps this is something to raise on rust internals. Thoughts?

from rust-url.

I've made my peace with this change after some discussion on rust internals - https://internals.rust-lang.org/t/stability-of-hash-values/2241.

It seems like my understanding of 'hash' is different to the popular one, so I'll see if I can improve the documentation of the hash trait to better spell it out for people like me.

from rust-url.

The serialization of URLs should be much more stable (since it affect interoperability and has a spec) so I’d recommend basing your hashing on that rather than the built-in Hash trait.

To avoid allocating a serialized string, you could have a specialized std::fmt::Write implementation that does the hashing.

from rust-url.