Пользовательский JSON IErrorHandler в WCF, возвращающий StatusCode 200/504, когда должен возвращать 400 - PullRequest
Новая
       14

Пользовательский JSON IErrorHandler в WCF, возвращающий StatusCode 200/504, когда должен возвращать 400

0 голосов
/ 17 августа 2010

У меня есть служба WCF, которая среди других привязок также использует WebHttpBinding для входных данных / результатов JSON.

Я сделал собственную реализацию IErrorHandler, чтобы иметь возможность установить StatusCode равным 400, когда что-то идет не так, а такжевернуть JSON понятное сообщение.Это прямая реализация, которую вы можете найти повсюду (хороший способ описан здесь ).

Моя проблема: когда я тестирую его локально с помощью Visual Studio Web Development Server (Cassini), он работает отлично.Однако, когда я развернул его на своем тестовом сервере (Windows 2008 со стандартным конфигом для IIS и всего остального), он не работает.

Когда я вызываю его и отлаживаю с Firebug, я получаю HttpStatusCode 200 в качестве возврата инет ответа.С Fiddler я получаю HttpStatusCode 504 и никакого возврата вообще.Однако поведение, которое я ожидал (и то, что происходит локально), является вызовом обратного вызова ошибки вызова ajax с установленным responseText.

Я отладил его удаленно, и все выглядит просто отлично.Конвейер выполнения в порядке, и все классы вызываются так, как они должны быть, как и локально, за исключением того, что он не работает.

Есть предложения?У меня практически нет вариантов, чтобы понять это.

Большое спасибо!

Ответы [ 2 ]

0 голосов
/ 15 июля 2016

У меня была похожая проблема, которую я смог решить. Посмотрите на настройки IIS. Подробные сведения о том, как я преодолел проблему, приведены в этом сообщении: IErrorHandler возвращает неправильное тело сообщения, когда код состояния HTTP 401 Не авторизован

0 голосов
/ 26 августа 2010

если firebug и fiddler дают разные результаты, что произойдет, если вы telnet к нему напрямую и выполните запрос (что-то вроде:) 

    GET /VirtualDirectoryAndGetData HTTP/1.1
    HOST: example.com
    [carriage return]

Меня не удивит, если вы как-то получаетенечетные заголовки / форматирование назад (чтобы объяснить причину несогласия firebug / fiddler)

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

Если это происходит где-то за пределами VS, вы также можете попробовать закомментировать строки, в которых вы установили 

  rmp.StatusCode = System.Net.HttpStatusCode.BadRequest;
  rmp.StatusDescription = "Bad request";

Это может указывать, является ли это проблемой с кодом ответа или проблемой с обработчиком ошибок.

Если вы можете отредактировать свой вопрос, включив в него результаты (с удалением конфиденциальной информации), мы посмотрим, сможем ли мы отследить его дальше.

Редактировать: после повторного рассмотрения вопроса вполне возможно, что сервер делает ошибку, прежде чем он сможет отправить ЛЮБОЙ ответ.FF может принять 200 по умолчанию, тогда как т.е. может принять 504 (время ожидания шлюза).Это полное предположение, но возможно.Вы видите что-нибудь в журналах событий?

...