It’s only when you’re moving to the genuine domains that small URL-parsing/concatenating bugs might show up. But there’s not many easy ways to “simulate” being on the actual twitter.com website with test code you’ve written. It’s doable, just not convenient. So, these sort of URL configs can very often be the one place that bugs essentially go “untested” in an imperfect workflow.
When I think about it, this is actually exactly the kind of bug that very easily passes to production.
You have your dev environment; something like “katanasdevmachine.twitterdev.com”, where you do your work and verify bugs. This environment is configured with a developer database, and developer URL configurations. So there might be “katanasdevmachine.twitterdev.com” simulating x.com, and then “briansdevmachine.twitterdev.com” to represent twitter.com. You and Brian do a test of the redirect from there, and all’s well.
It’s only when you’re moving to the genuine domains that small URL-parsing/concatenating bugs might show up. But there’s not many easy ways to “simulate” being on the actual twitter.com website with test code you’ve written. It’s doable, just not convenient. So, these sort of URL configs can very often be the one place that bugs essentially go “untested” in an imperfect workflow.
I mean, /etc/hosts, but I see your point. I’d guess this might be a case of, “this is pretty simple, we’re good to go”. then “oops”
Yeah that’s true