[nomurrcy]

This is 'fixed' however in a bunch of server-side frameworks. (I'm not sure about rails, I don't use it)

I've used a hack (I think lifted from django) whereby if you are running firefox and and your request came in with an x-requested-with header and we redirect you, we keep a marker in your session that we just redirected you to url x via xhttp request and store any other custom headers we might have set.

Then when your subsequent request comes in (with all its custom headers including x-requested-with missing) we re-add the headers that were stripped out and route your request based on the infered headers. We only keep this lookup entry around for a very short time (like 30 seconds) and remove it after the first time it is used.

It is a total hack, but it works in most cases. Not using redirects on xmlhttp requests is pretty limiting - it is a real shame that the FF devs took so long to fix this bug as it now exits in tons of installs that will probably be around for years to come.

[masklinn]

> It is a total hack, but it works in most cases.

yeah I had to do that kind of stuff as well.

> Not using redirects on xmlhttp requests is pretty limiting

I don't agree. The reality is that it should not be needed, redirect-after-post (let alone DELETE or PUT) is a workaround for browser UI issues ("Do you want to re-send this POST request" popups on refresh) and URI localization (bookmarkability of the landing page). There are reasons for redirects in xhr scenarios, but they have to do mostly with clients "caching" old URLs and the service changing its URI structure.

There's little to no reason to send a redirect (let alone a temporary one) to an XHR.