Подтвердить что ты не робот

Проблема отправки JSON-данных из JQuery в метод REST WCF

У меня возникли проблемы с загрузкой jquery, чтобы опубликовать некоторые данные json для метода rest, который у меня есть в моей службе WCF.

На стороне WCF здесь заключен рабочий договор:

[OperationContract]
[WebInvoke(Method = "POST",
           BodyStyle = WebMessageBodyStyle.Bare,
           RequestFormat = WebMessageFormat.Json,
           ResponseFormat = WebMessageFormat.Json,
           UriTemplate = "PostSomething")]
MyResult PostSomething(MyRequest request);

оба MyResult и MyRequest отмечены всеми необходимыми атрибутами DataContract и DataMember, а служба - подвергает конечную точку WebHttp.

На стороне JQuery здесь вызывается моя функция:

var jsonStr = JSON.stringify(reqObj);

$.ajax({
    type: "POST",
    dataType: "json",
    url: "http://localhost/MyService/PostSomething",
    contentType: "application/json; charset=utf-8",
    data: jsonStr,
    success: function (html) {
        alert(html);
    }
});

этот запрос никогда не достигает моего метода (я получаю метод 405, который не разрешается каждый раз), и, глядя в Карл, запрос выглядит следующим образом:

OPTIONS /MyService/PostSomething HTTP/1.1
Host: localhost
Cache-Control: max-age=0
Access-Control-Request-Method: POST
Origin: null
Access-Control-Request-Headers: Content-Type, Accept
Accept: */*
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.237 Safari/534.10
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Несколько вещей, которые странно об этом:

  • метод OPTIONS не POST
  • тип содержимого (на другой вкладке) показывает text/html; charset=UTF-8 вместо json
  • данные JSON не могут быть замечены

Однако, если я изменю запрос в Charles, чтобы его заголовки были похожи на решение здесь, тогда все работает:

POST /MyService/PostSomething HTTP/1.1
Content-Type: application/json; charset=utf-8
Host: localhost
Content-Length: 152

{"Id":"", "Name":"testspot","Description":"test" } 

глядя на учебные пособия и другие вопросы, здесь другие смогли получить JQuery для публикации в методе REST WCF, подобном этому, и я не понимаю, что я здесь делаю неправильно.

oh, чтобы поместить некоторый контекст, это служба WCF 4, и я использую JQuery 1.4.4.

Спасибо,

UPDATE:

После некоторого большего чтения и спасибо Darrel за то, что он указал мне на междоменную спецификацию, мне удалось немного улучшить некоторые мои изменения в сервисе:

[OperationContract]
[WebInvoke(Method = "*",
           BodyStyle = WebMessageBodyStyle.Bare,
           RequestFormat = WebMessageFormat.Json,
           ResponseFormat = WebMessageFormat.Json,
           UriTemplate = "PostSomething")]
MyResult PostSomething(MyRequest request);

и в реализации мне нужно проверить, есть ли входящие запросы для OPTIONS, и в этом случае вернуть некоторые заголовки, а не выполнять намеченную работу:

if (WebOperationContext.Current.IncomingRequest.Method == "OPTIONS")
{
    WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Origin", "*");
    WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Methods", "POST");
    WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Headers", "Content-Type, Accept");

    return null;
}

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

4b9b3361

Ответ 1

Это похоже на Firefox, чтобы избежать перекрестных вызовов. См. http://www.petefreitag.com/item/703.cfm

Спецификация для этого здесь http://www.w3.org/TR/cors/ и после очень короткого чтения кажется, что, поскольку вы выполняете вызов перекрестного домена, ожидается, что ваша служба внедрит метод OPTIONS и вернет некоторые заголовки, которые позволяют отправлять POST-метод.

Ответ 2

Обновление по вопросу, содержащему предлагаемое решение, имеет некоторые проблемы. Проблема заключается в том, что если ваш вход не поддерживает метод POST, запрос OPTIONS фактически не возвращает правильные разрешенные заголовки. На самом деле он не смотрит, какие методы фактически разрешены на конечной точке WCF - его просто искусственное выражение "POST" разрешено для каждой отдельной конечной точки в приложении, когда клиент выполняет запрос OPTIONS (который на самом деле является клиентом, запрашивающим то, что поддерживается).

Это, вероятно, хорошо, если вы действительно не полагаетесь на информацию в методе OPTIONS, чтобы вернуть вам правильный список методов (как в случае с некоторыми запросами CORS), но если вы находитесь, вам нужно будет сделайте что-нибудь вроде решения по этому вопросу: Как обрабатывать запрос AJAX JACKERY POST с самообслуживанием WCF

В принципе, каждая конечная точка должна реализовывать:

Webinvoke(Method="OPTIONS", UriTemplate="")

и вызовите соответствующий метод, который загружает соответствующие заголовки в ответ (включая правильный список "Access-Control-Allow-Method" для этой конечной точки) вызывающему. Это отвратительно, что размещенные конечные точки WCF не делают этого для нас автоматически, но это временное решение, которое позволяет более точно контролировать конечную точку. В этом решении правильные заголовки ответов загружаются в реализацию конечной точки:

public void GetOptions()
    {
        // The data loaded in these headers should match whatever it is you support on the endpoint
        // for your application. 
        // For Origin: The "*" should really be a list of valid cross site domains for better security
        // For Methods: The list should be the list of support methods for the endpoint
        // For Allowed Headers: The list should be the supported header for your application

        WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Origin", "*");
        WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Methods", "POST, GET, OPTIONS");
        WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Headers", "Content-Type, Accept, Authorization");
    }

В дополнение к этому вы должны установить флаг "CrossDomainScriptAccessEnabled" либо в файле web.config для конечной точки привязки, либо в коде для WebHttpBinding при настройке конечной точки. В противном случае вы снова будете лежать в ответе своего заголовка, когда вы скажете: "Access-Control-Allow-Origin" - "*" (или список URL-адресов)

Ответ 3

Update:

Попробуйте поставить .svc после MyService, чтобы URL-адрес читал

http://localhost/MyService.svc/PostSomething

Я работал над этим на днях сам и наткнулся на сообщение в блоге Рика Страхла:

http://www.west-wind.com/weblog/posts/324917.aspx

Это работает безупречно для меня, поэтому попробуйте!

Надеюсь, что это поможет!:)

Ответ 4

В вашем web.config вы использовали webhttpbinding?

только webhttpbinding поддерживает json.

Ответ 5

Я просто отправлю короткий ответ, который помог мне, потому что другие ответы не сделали.

  • Сценарий: вызов ajax для службы wcf.
  • Ошибка: автоматический запрос OPTIONS от ajax перед отправкой POST запрос. Первый запрос не мог быть обработан моей службой.
  • Решение: разрешить запрос OPTIONS и отвечать на него.

Что вам нужно сделать:

  • Добавьте это в web.config:

    <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Access-Control-Allow-Origin" value="*" />
        <add name="Access-Control-Allow-Methods" value="GET,PUT,POST,DELETE,OPTIONS" />
        <add name="Access-Control-Allow-Headers" value="Content-Type" />
      </customHeaders>
    </httpProtocol>
    

  • Добавьте это в Global.asax.cs(если у вас нет этого файла в вашем решении, а затем создайте его: Добавить новый элемент = > Visual С# = > Глобальный класс приложения (имя по умолчанию - "Глобальное .asax" )):

    protected void Application_BeginRequest(object sender, EventArgs e)
    {
        if (HttpContext.Current.Request.HttpMethod == "OPTIONS")
                        HttpContext.Current.Response.End();
    }