HttpWebRequest возвращает 404 с на 302 с только в Internet Explorer

Question

У меня есть приложение Silverlight (v3), которое использует WebRequest для отправки запроса HTTP POST на веб-страницу на том же веб-сайте, что и приложение Silverlight. Этот HTTP-запрос возвращает 302 (перенаправление) на другую страницу того же веб-сайта, за которой автоматически следует HttpWebRequest ( согласно документации ).

Нет ничего особенно особенного в коде, который выполняет запрос (он использует стек HTTP браузера, он не настроен на использование альтернативного встроенного стека HTTP Silverlight):

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(String.Format("{0}?name={1}&size={2}", _UploadUrl, Uri.EscapeUriString(Name), TotalBytes));
request.Method = "POST";

Все это прекрасно работает в Firefox и Chrome; Silverlight выполняет HTTP-запрос POST, получает ответ 302 и автоматически выполняет HTTP-запрос GET с указанным URL-адресом перенаправления и возвращает его мне (я знаю это, потому что я использовал Fiddler для наблюдения за происходящими HTTP-запросами). Однако в Internet Explorer (v8) Silverlight выполняет HTTP-запрос POST, а затем выдает WebException с кодом ошибки 404!

Используя Fiddler, я вижу, что Silverlight / Internet Explorer успешно возвратил код состояния 302 для запроса, и я предполагаю, что код состояния 404 (и соответствующее исключение WebException), который я получаю в Silverlight, потому что, насколько я знаю, HTTP-запросы, выполняемые через стек браузера, могут возвращать только 200 или 404 из-за ограничений. Настоящий вопрос - , почему Internet Explorer не выполняет перенаправление, как другие браузеры ?

Заранее спасибо за любую помощь!

РЕДАКТИРОВАТЬ: Я бы предпочел не использовать HTTP-стек клиента Silverlight, так как к моим запросам знаний, выданным им, не относятся файлы cookie, являющиеся частью сеанса браузера, критически важные, включая проверку подлинности ASP.NET. файл cookie, который необходимо прикрепить к HTTP-запросам, выполняемым элементом управления Silverlight.

РЕДАКТИРОВАТЬ 2: Я обнаружил, что Internet Explorer проявляет это поведение только при выполнении запроса POST. Запрос GET перенаправляет успешно. Это кажется довольно плохим поведением, учитывая, сколько веб-сайтов в настоящее время работают в стиле Post-Redirect-Get.

Answer 1

IE ближе к спецификации, так как в ответ на 302 для POST пользовательский агент должен отправить POST (хотя он не должен делать это без подтверждения пользователя).

С другой стороны,FF и Chrome намеренно ошибаются, копируя способы, которыми пользовательские агенты часто ошибались некоторое время назад (проблема возникла в первые дни HTTP).

По этой причине в HTTP / 1.1 было введено 307чтобы было понятнее, что должен использоваться один и тот же метод HTTP (т. е. в данном случае это должен быть POST), а 303 всегда означал, что следует использовать GET.

Поэтому вместо выполнения Response.Redirect, что приводит кв 302 - что разные пользовательские агенты будут обрабатывать по-разному, отправьте 303. Следующий код делает это (и включает в себя действительное тело сущности только для того, чтобы находиться в пределах буквы спецификации).Существует перегрузка, поэтому вы можете вызвать ее с помощью Uri или строки:

private void SeeOther(Uri uri)
{
  if(!uri.IsAbsoluteUri)
    uri = new Uri(Request.Url, uri);
  Response.StatusCode = 303;
  Response.AddHeader("Location", uri.AbsoluteUri);
  Response.ContentType = "text/uri-list";
  Response.Write(uri.AbsoluteUri);
  Context.ApplicationInstance.CompleteRequest();
}
private void SeeOther(string relUri)
{
  SeeOther(new Uri(Request.Url, relUri));
}

Answer 2

Я полагаю, что это было изменение функции в Internet Explorer 7, где они изменили ожидаемый ответ 200 на 302, сообщая IE о перенаправлении.Я не знаю плавного решения этой проблемы.Подобный вопрос был задан некоторое время назад здесь .

Изменение поведения в Internet Explorer 7 и более поздних версиях относительно запросов CONNECT