This has not affected any real-world app I use. I noticed this while working on a bidirectional hash gem (bihash@rubygems). However, I don't think the behavior is consistent with the spec as written: The spec merely says that keys are c...cohen (Cohen Carlisle)
Hash seems to have very inconsistent behavior for `==`, `>=`, and `<=`. Given that below h1 == h2 is `false` and that they have the same number of keys, I would expect `<=` and `>=` to also be `false`. However, surprisingly `h1 <= h2` ...cohen (Cohen Carlisle)
I'm not sure I think this is exactly the same as https://bugs.ruby-lang.org/issues/2567, as that one has focused on using the HTTP headers to guess the content type. Here I'm pointing out that ASCII-only strings are recognized as UTF8, b...cohen (Cohen Carlisle)
I created a case at https://github.com/Cohen-Carlisle/utf8app that shows Net::HTTP labeling a response body as ASCII-8BIT encoded because it contains a non-ascii character (specifically, the double prime symbol: ″), but recognizing ascii...cohen (Cohen Carlisle)
cohen (Cohen Carlisle)03:02 PM Ruby Bug #21921: Hash inconsistent ==, >=, <= behavior