Why Content-Length is 0 while sending POST request with XMLHttpRequest object?

Question

I have a virtual directory on IIS 5.1 with two aspx pages. Access to Page1 configured as "Integrated Windows Authentication" option turned on and anonymous access is disabled. Page2 available through anonymous access. On client side there is XmlHttpRequest object that can send requests that contains POST data to this pages.

At first I try to send request to Page1. Standard Windows Authentication dialog appears, I entering my credentials and Page1 succesfully receiving POST data. After that I try to make the same POST request to Page2 that can be accessed anonymously. And in this case Request has header Content-Length=0, and no any data has been sended.

If to repeat request to Page1 - it successfully receiving POST data. The same code is working good in Firefox 3.5. Page2 can receive data even after sending request to Windows Authentication required Page1. What can be wrong? And maybe it is any workaround for this problem?

Thanks!

Sending data:

function sendRequest() {
  var url = "http://tom/AuthTest/Default.aspx";
  var data = "data";
  reqSend(url, data);
}

function sendRequestToWinAuth() {
  var url = "http://tom/AuthTest/DefaultWA.aspx";
  var data = "newdata";
  reqSend(url, data);
}

function reqSend(url, data) {
  var xmlhttp = createRequestObject();
  if (!xmlhttp) {
    alert("Cannot create XMLHttpRequest object.");
    return;
  }
  try {
    xmlhttp.open("POST", url, false);
    xmlhttp.send(data);
  }
  catch (ex) {
    alert("Error: " + ex.message);
  }
}

Request to Page1:

POST /AuthTest/DefaultWA.aspx HTTP/1.1
Accept: */*
Referer: http://tom/AuthTest/client/testauth.html
Accept-Language: ru
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: tom
Content-Length: 7
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: innovator_user=admin
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAF4AAAAYABgAdgAAAAoACgBIAAAABgAGAFIAAAAGAAYAWAAAAAAAAACOAAAABYKIogUBKAoAAAAPcwBjAGEAbgBkAHQAbwBtAFQATwBNAGUdQIkWMQ6PAAAAAAAAAAAAAAAAAAAAAAo3goJdI7RH9poJwnjypksH2F2pIzbEOQ==

newdata

Request to Page2:

POST /AuthTest/Default.aspx HTTP/1.1
Accept: */*
Referer: http://tom/AuthTest/client/testauth.html
Accept-Language: ru
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: tom
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: innovator_user=admin
Authorization: Negotiate TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==
Content-Length: 0

Answer 1

I've had this exact problem, apparently its by design in IE, check out this link: http://www.websina.com/bugzero/kb/browser-ie.html

Basically IE won't send POST data to an unauthenticated URL/page if you are currently on an authenticated URL/page. I didn't find a work-around, I had to do something else, but let me know if you do figure out a way. Cheers

Answer 2

Seems i have found a way to keep pages requiring windows authentication and pages allowing anonymous access on one site.

There 2 ways to do it:

1) This behavior (bug) is only reproducing when using NTLM authentication. So to avoid it, we can setup a Kerberos authentication mode on IIS site. Here is a good detailed FAQ about IIS and Kerberos: http://www.adopenstatic.com/faq/

To tell a thruth I have tried to follow the first way, but really my IIS doesn't want to use Kerberos anyway. On other hand I try to check this situation on another machine - and was surprised - Kerberos authentication was used there by default. I have tried to found any differents in configurations - but not successfull. So there is the second way:

2) Using Windows Authentication mode on a directory or file in a separate directory. For example we have some structure like:

../Default.aspx

../auth/DefaultWinAuth.aspx

../auth/DefaultWinAuth2.aspx

We can set IWA (Integrated Windows Authentication) mode on 'auth' directory or DefaultWinAuth page. After that all files and subdirectories that are included in this folder or situated on the same level as 'DefaultWinAuth.aspx' page will not be able to receive POST data. But all other files and directories outside directory 'auth' will work fine.