Служба и предпросмотр RESTful.NET

Я разрабатываю веб-службу RESTful с WCF и C#. Служба работает нормально, но когда я сделал запрос со статической HTML-страницы, используя XMLHttpRequest, все браузеры, кроме IE (кто еще?), Сначала отправляют предварительное сообщение (https://developer.mozilla.org/en/http_access_control) с запросом доступных параметров для этой услуги. Такие сообщения появляются только при изменении заголовков сообщения, чтобы отправить запрос POST.Служба и предпросмотр RESTful.NET

Мой вопрос/предложение: Вы знаете какой-либо способ оказать поддержку этому виду сообщений на WCF/.NET? Моя идея - реализовать метод обработки предполетного сообщения; ответ будет стандартным ответным сообщением со всеми доступными параметрами (GET, PUT, POST, DELETE), поскольку все эти операции будут доступны, а также укажет, что единственным типом данных, доступных для данных в сообщениях, является JSON. После ответа обычный запрос будет отправлен браузером, поэтому все должно работать правильно.

Как вы думаете?

источник

2010-11-11 jmpcm

Почему бы вам просто не добавить решение LS (многоуровневая система) и работать с обратным прокси-сервером? Звучит как hassel, чтобы написать рутину, просто используемую для IE. – Anders

В этом случае IE это не проблема, все остальные: P IE не отправляет сообщение перед полетом, поэтому служба работает нормально. Все остальные браузеры отправляют сообщение перед полетом, и его необходимо обрабатывать, поэтому необходимо, чтобы подпрограмма обрабатывала его. Вероятно, IE будет иметь эту функцию, реализованную в версии 9, поэтому на самом деле не так просто написать рутину, потому что она понадобится в будущем. – jmpcm

Проблема решена! Я установил атрибут Method с *, и теперь он отлично работает: сначала предоставляется запрос на предполетный запрос, а затем принимается и обрабатывается реальный запрос. Код следующим образом:

[OperationContract] 
[WebInvoke(UriTemplate="*", Method = "*")] 
void HandleHttpOptionsRequest();

источник

2010-11-15 11:32:20 jmpcm

Где мы должны добавить это? –

Вы можете поддерживать ОПЦИИ так же, как вы поддерживаете POST с помощью атрибута WebInvoke. Просто измените метод. В запросе OPTIONS нет ничего особенного. Вам просто нужно установить заголовок Allow в ответе.

источник

2010-11-11 12:23:10

Привет, Даррел! Спасибо за ответ и извините за задержку. Найдите ответ ниже. Я попытался установить атрибут OPTIONS on Method, но он не сработал ... Я решил его с помощью *. Вы когда-нибудь делали это с ОПЦИЯми по атрибуту метода? Заранее спасибо! – jmpcm

@jmpcm Нет Я никогда не использовал ОПЦИИ, но я использовал метод PATCH с помощью WebInvoke. Не уверен, почему метод OPTIONS не работает для вас. –

[OperationContract] 
[WebInvoke(UriTemplate="*", Method = "*")] 
void HandleHttpOptionsRequest();

Это отличное решение, и вы можете реализовать IDispatchMessageInspector добавить необходимые заголовки CORS довольно легко.

источник

2015-01-21 23:58:15 dobos

Добро пожаловать в переполнение стека! Вероятно, это был комментарий к ответу, на который вы получили код, а не сам ответ. С немного больше rep, [вы сможете оставлять комментарии] (http://stackoverflow.com/privileges/comment). –

Служба и предпросмотр RESTful.NET

ответ

Смежные вопросы