Question

I am creating an extension targeted at a specific site whose servers I do not have access to. I am attempting to handle HTTP 302 redirects in a way that lets me use a HEAD request to get the redirect url. My code for doing so is this:

var redirUrl = "";
var requestId = 0;

chrome.webRequest.onBeforeRedirect.addListener(function(details){
  console.log("before redirect");
  if(details.method == "HEAD"){
    redirUrl = details.redirectUrl;
    requestId = details.requestId;
  }
},
{urls: [matchUrl]});

chrome.webRequest.onHeadersReceived.addListener(function(details){
  console.log("on headers received");
  if(details.requestId == requestId){
    var temp = {"name":"redirUrl","value":redirUrl};
    details.responseHeaders.push(temp);    
  }  
  return {responseHeaders:details.responseHeaders};  
},
{urls: [matchUrl]},["responseHeaders", "blocking"]);

chrome.webRequest.onCompleted.addListener(function(details){
  console.log(JSON.stringify(details.responseHeaders));
},
{urls: [matchUrl]},["responseHeaders"]);

Now currently the matching is non specific enough to trigger these events with normal navigation to a matched url. Upon doing so things proceed perfectly fine, of course not being a HEAD request it does not add anything. Even if I allow all redirected requests, the header is added just fine. My problem arises when I try to call this in a different place in my background js file:

 $.ajax({
   url: url,
   data: datas,
   type: "HEAD",
   success: function(data,statusCode, jqXHR){
     console.log(jqXHR.getAllResponseHeaders());
   }      
 }); 

The blocking part of the onHeadersRecieved listener prevents the event from being fired at all, and if I remove the blocking there is not enough time to append the header. So my question would be what could be preventing it from firing the event properly?

Answer 1

Well it seems that this is a bug in chrome and not in my code and the fix should work its way down to the stable channel at some point, hopefully sooner rather than later. I believe it may be this issue, or at least related to it, and this code is confirmed to work in 26.0.1386.0 canary.