I am assuming your hosts are using the Atomicorp mod_security rule set. The error "Remote File Injection attempt in ARGS" is documented here; you can see the code here.
This rule disallows input that looks like a URL from all fields, on the assumption that any mention of a URL is an attempt to get the application to fetch and execute the content at that URL. This is vanishingly unlikely and pretty pointless, but no-one said WAFs were clever.
Because naturally this breaks almost every site, the rule includes loads of exceptions for widely-used web applications. It looks like if you put a string that resembles a known application in your URL (eg
jomsocial/x/add), or use a known application's parameter name for your URL (eg
origin), you'd probably be able to evade the rule. Of course the exceptions list contains lots of applications that actually have suffered from multiple serious security holes, but no-one said WAFs were clever.
In general WAFs like this and other complex mod_security rulesets aren't much good as intrusion protection for general-purpose web applications. They need specific configuration to recognise what input is and isn't expected, and for custom applications you wrote yourself the effort involved in doing that configuration is usually better spent making sure input is handled appropriately in the application itself.
(They can be useful for intrusion attempt detection, and for patching up problems in someone else's software you can't change - or as a temporary measure until you can fix it properly. But blanket-deploying them against random custom software is not sensible, and rewriting custom software to circumvent WAF blocks isn't really productive or sustainable.)
If your hosting company insists on using an instance of mod_security outside your control to block perfectly valid application input, I would look for a hosting company with more clever.