AJAX redirect dilemma, how to get redirect URL OR how to set properties for redirect request

Based on your question, I am not entirely sure if you are referring to HTTP Authentication or a form-based authentication scheme, and therefore I will address both.

Get the redirect URL so I can send a second request (xhr.getResponseHeader("Location") does NOT work),

With the way XHR is built in general (and in Chrome specifically):XHR is not very flexible, and provides a relatively high-level API, with the same behavior the browser has in all other requests (address bar urls, image source urls, embedded script urls), i.e. redirects are handled transparently. No events will be thrown in the JavaScript alerting you of this redirect or the intermediate 302/301 status codes, you will only receive the final status code and data. Therefore, it is impossible to retrieve the "Location" header from the response, as the final response will not contain the "Location" header.

Have the new redirect request preserver the settings from the original request,

XHR does not provide this as an option and it would be an incorrect default behavior. Example for why this would and should not happen for default:

Acme corp provides a URL short-linking service for its employees. I click on a short-link I receive from a co-worker and am prompted with HTTP authentication by Acme's short-linking service. The redirect occurs following this authentication. There is no reason the site being redirected to should require my credentials, and therefore it would be incorrect behavior for the browser to pass this information on (and in fact a security issue). Similarly, POST data should not be forwarded as it could only be intended for consumption by the pre-direct URL .

Get the final URL that the error came from so I can send another request.

Unfortunately, for security reasons, and standards definition, the standard XHR object (including the one Chrome uses for cross-site requests in extensions) does not provide any way to access the final URL which has an error. You can only access the final HTTP status and any data returned by the final URL.

--

Given this, you have a few options depending on how much control you have over the situation:

1) If you have control over the redirection server, consider including info. in your AJAX requests indicating an AJAX client, and have the server instead return data (i.e. a json object) indicating that a redirect should be made.

Or, if it is the intention to always pass on authentication data, consider implementing some mechanism for session-passing or including authentication info. in the URL being redirected to so the destination URL can consume this info.

2) If you have control over the destination of the redirect, consider including the URL of the destination when generating an authentication failure page. The XHR object will have access to this response data and can parse it to proceed with a new request.

3) If you have no control over either the redirection site or the destination site, consider hosting a proxying server to handle requests and catch 302's specifically.

http://myserver/?url=http://redirectsite.com&user=...&pass=...

4) If none of the above are options, the least desirable, yet viable option, is to build an NPAPI extension for Chrome that runs native code. This will give you full control over requests, and allow you to do pretty much anything. However, note this is at the expense of more complex development, potential security issues, and less user desirability.

Unfortunately there is no way to prevent xhr from auto-following redirects or set credentials for the redirect destination (it would be rather insecure anyway since that would allow the first site to redirect the credentials to any site, not only the one you want to get them).

You could try the type of solution described here:How to manage a redirect request after a jQuery Ajax call

That means in fact superseding HTTP protocol, you'll need to control the server as well. All ajax responses will be in code 200 (or at least the 3xx ones, not the 401/403) with a json object. and in this json object you can provide some special error code (why not reusing

Then you extends jQuery.ajax function to capture theses special codes in your json response and make the new requests needed. In fact the automatic jQuery redirect call is done by you and not by jQuery.

at first this seems ugly, but when dealing with problems like the one suggested in the link (end of session, redirect on login page) it seems that having a complete protocol handling in your ajax json communications between the client and the server is not a bad idea.