Replying to [comment:5 jaubourg]:
No, actually, 1.5 added cross-domain detection. 1.4.4 just didn't bother controlling this and just let the browser's implementation throw an exception when it couldn't handle the request. With the new transport architecture, it makes sense to control this, seeing as it makes it possible to provide fail-over transports in browsers that doesn't support cross-domain. Anyway: 1) Do you absolutely need to use the encoded url? 2) Can't you use urls with no domain name (/something_on_the_server)? I don't really get why you're using the encoded domain name in your urls. It seems pretty easy (and much simpler for you incidently) to use the domain name unencoded. Or am I missing something gigantic here?
Ah. I see.
I didn't write this bug report for my own selfish needs :), but to bring an undocumentet "broken" (in a way) behavior up to the community. Cross browser behavior is one of the jQuery features I appreciate the most.
There is, as you say, several workarounds for it. But for people upgrading existing systems from 1.4.4 to 1.5+ it can be real annoying to debug and not finding any information about this error (at least I didn't).
I'm not the original creator of the system I found this behavior in, but I think the reason for using the encoded domain is that the absolute URL is set server side with PHP. Server-side, the host name is always returned encoded. I don't think it's that uncommon to use an absolute URL for ajax calls, and with that, an encoded IDN. In more complex systems it might even be necessary. I find it kind of strange that no one else have reported this behavior (as far as I know).