Запрос обрабатывается нормально, когда выдается браузером, но не когда приложение ASP.NET на том же компьютере

Question

Я отлаживаю два приложения ASP.NET, работающие на одной машине под разными экземплярами Cassini и с отключенными «пользовательскими ошибками».Одно приложение работает на порту 100 и хочет выполнить запрос GET от другого приложения, работающего на порту 90. Таким образом, оно выполняет следующий код:

WebRequest request = WebRequest.Create(
   "http://localhost:90/Controller/Action?Param1=foo&Param2=bar");
request.Timeout = 10000;
request.GetResponse();

, а последняя строка выдает WebException сHTTP 400 код и нулевое InnerException.Если я скопирую тот же URL-адрес в буфер обмена, вставлю его в IE, работающий на той же машине - запрос помещается в очередь приложения на порт 90, и вызывается его /Controller/Action/, и даже параметры передаются нормально.В чем может быть причина проблемы и как ее решить?

Answer 1

Я бы попытался использовать перегрузку WebRequest.Create, которая принимает объект URI , чтобы вы могли исключить жирный URL.

Answer 2

Я думаю, вы должны попробовать без параметров в URL.

WebRequest request = WebRequest.Create("localhost:90/Controller/Action");
request.Timeout = 10000;
request.GetResponse();

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

Также вам стоит взглянуть на WebClient. MSDN

лично я бы также рассмотрел использование IISExpress или IIS для разработки такого решения.

Просто наблюдение стороннего наблюдателя, рассмотрите возможность сделать этот вызов второму веб-методус помощью вызова ajax из браузера и агрегирования результатов на стороне клиента с использованием javascript (jQuery).

Answer 3

Отладка в течение двух часов - и оказалось, что служба на порту 90 перенаправит запрос обратно службе на порт 100, но не предоставит обязательный параметр в URL, поэтому обработчик службы на порту 100 будет выбрасывать исключение и вернуть HTTP 400, о котором затем сообщил GetResponse(). Решением было изменить логику так, чтобы не было перенаправления для этого конкретного запроса, потому что перенаправление не имело бы смысла для этого конкретного запроса.

И присяжные признают Кассини и ASP.NET невиновными.