Adrien Rey-Jarthon

PR is here: #496

~Quick~ question, I encountered a similar issue where IDNA::Pure normalization was not matching browser behavior (and after testing, not matching IDNA::Native either): ```ruby irb(main):004:0> s1 = "https://l♥️h.ws" => "https://l♥️h.ws" irb(main):005:0>...

@dentarg thanks for your input 🙇‍♂️ So I started adding the spec for my case and then looked at the code to find where to.. _OH MY GOD WHAT THE...

I really shouldn't have opened this pandora box 😅 Sooooo, as I've spent the weekend reading the [UTS#46 specification](https://unicode.org/reports/tr46/), I'll try to summarise the situation. - **IDNA2003** is the older...

@brasic as #492 has just been merged, this issue is now fixed in the `main` branch.

I also hit the same problem and was very surprised, after writing all my green tests with `expect(MyJob).not_to have_enqueued_sidekiq_job` I decided to double check their robustness by breaking the code...

@cgunther Indeed that example you gave is less common for me (because when I test the presence of a Job I want to make sure it's the right one too...

Indeed, that's another good example :) I could take a stab at a PR but I am already spending a lot energy writting PRs and maintaing forks for abandonned projects...

I like this block version indeed :+1: It won't solve the initial issue though, which is the unexpected behavior of the existing syntax. Both in comparison with similar rspec matchers...

For the record, I just tested this `rack-3` branch (#1859) on a small [website of mine](https://flight.adrienjarthon.com/), it's currently in production and working fine. It's not the type of app which...