Почему Content-Length равен 0 при отправке запроса POST с объектом XMLHttpRequest? - PullRequest
3 голосов
/ 06 августа 2009

У меня есть виртуальный каталог на IIS 5.1 с двумя страницами aspx. Доступ к Page1 настроен как опция «Интегрированная проверка подлинности Windows» и анонимный доступ отключен. Страница2 доступна через анонимный доступ. На стороне клиента есть объект XmlHttpRequest, который может отправлять запросы, содержащие данные POST, на эти страницы.

Сначала я пытаюсь отправить запрос на Page1. Появится стандартное диалоговое окно проверки подлинности Windows, я ввел свои учетные данные и успешно получил данные POST. После этого я пытаюсь сделать тот же POST-запрос к Page2, к которому можно обратиться анонимно. И в этом случае Запрос имеет заголовок Content-Length = 0, и никакие данные не были отправлены.

Если повторить запрос к Page1 - он успешно получил данные POST. Тот же код хорошо работает в Firefox 3.5. Страница2 может получать данные даже после отправки запроса на проверку подлинности Windows. Что может быть не так? А может быть, есть какое-то решение этой проблемы?

Спасибо!

Отправка данных:

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);
  }
}

Запрос на страницу 1:

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

Запрос на страницу 2:

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

Ответы [ 2 ]

2 голосов
/ 10 августа 2009

Кажется, я нашел способ сохранить страницы, требующие аутентификации Windows, и страницы, позволяющие анонимный доступ на одном сайте.

Есть 2 способа сделать это:

  1. Это поведение (ошибка) воспроизводится только при использовании аутентификации NTLM. Поэтому, чтобы избежать этого, мы можем настроить режим аутентификации Kerberos на сайте IIS. Вот хороший подробный FAQ по IIS и Kerberos: http://www.adopenstatic.com/faq/

    Честно говоря, я пытался следовать по первому пути, но на самом деле мой IIS все равно не хочет использовать Kerberos. С другой стороны, я пытаюсь проверить эту ситуацию на другом компьютере - и был удивлен - там по умолчанию использовалась аутентификация Kerberos. Я попытался найти какую-либо разницу в конфигурации - но не удалось. Итак, есть второй способ:

  2. Использование режима проверки подлинности Windows для каталога или файла в отдельном каталоге. Например, у нас есть такая структура, как:

    • .. / Default.aspx
    • .. / авт / DefaultWinAuth.aspx
    • .. / авт / DefaultWinAuth2.aspx

    Мы можем установить режим IWA (встроенная проверка подлинности Windows) в каталоге «auth» или на странице DefaultWinAuth. После этого все файлы и подкаталоги, которые включены в эту папку или находятся на том же уровне, что и страница DefaultWinAuth.aspx, не смогут получать данные POST. Но все остальные файлы и каталоги вне каталога 'auth' будут работать нормально.

1 голос
/ 06 августа 2009

У меня была именно эта проблема, по всей видимости, в IE, проверьте эту ссылку: http://www.websina.com/bugzero/kb/browser-ie.html

В основном IE не будет отправлять данные POST на неаутентифицированный URL / страницу, если вы в настоящее время находитесь на аутентифицированном URL / странице. Я не нашел обходной путь, я должен был сделать что-то еще, но дайте мне знать, если вы найдете способ. Приветствия

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...