Вы запрашиваете x-www-form-urlencoded, а angular в настоящее время не кодирует данные таким образом. Я полагаю, мы могли бы, но я не уверен, что ожидаю, что это произойдет. Я думаю, что на данный момент вам следует просто использовать jQuery, когда вам нужно отправлять такие запросы, и, возможно, если вы хотите реализовать эту функцию, мы могли бы рассмотреть возможность включения ее в дерево. Я отмечу это как приветствие PRz.

Связано с https://github.com/angular/angular.js/issues/1743. Я согласен с @caitp в том, что мы могли бы легко облегчить жизнь людям. Думаю, мы могли бы попробовать сделать следующее:

• обнаружить заголовок x-www-form-urlencoded и соответственно сериализовать данные
• проверьте, имеют ли данные тип https://developer.mozilla.org/en-US/docs/Web/API/FormData (но это работает только в IE 10+, если я не ошибаюсь)

Имеет ли смысл разместить эту функциональность в отдельном модуле вне ядра? Имея его вне ядра, можно было бы легко расширить его и таким же образом поддерживать другие форматы.

Я собрал доказательство концепции и демонстрацию Plunker . Если это кажется правильным направлением, я буду рад продолжить его разработку.

+1

По личным наблюдениям, все, что мне нужно сделать, чтобы это data - это обернуть свойство $.param чтобы публикация форм работала как обычно.

Бывший.

$http({
    url: ServerAddress+"/login", method: 'POST',
    data: $.param($scope.loginForm),
    headers : {'Content-Type':'application/x-www-form-urlencoded; charset=UTF-8'}
})

Я считаю, что это упростило бы жизнь, если бы AngularJS мог предоставить функцию, эквивалентную jQuery $.param - в идеале то, что можно было бы использовать также со свойством transformRequest .

+1. Исходя из темы на # 1743, я согласен с тем, что эта функция отсутствует в Angular. Моя команда была на самом деле очень удивлена, обнаружив, что есть обручи, через которые нужно перепрыгнуть, чтобы сделать сообщение обычной формы. В нашем случае у нас есть jQuery в качестве зависимости, поэтому мы можем использовать его, пока Angular не получит «родное» решение.

Столкнувшись с той же проблемой. Недавно начал работать над приложением HTML5 (Cordova), которое вызывает серверную часть PHP для HTTP-запросов. Бэкэнд PHP поддерживает ряд различных проектов, поэтому даже простые вызовы, такие как вход в систему и аутентификация, ожидают form-data или application/x-www-form-urlencoded .

Мне очень понравились части AngularJS, которые я использовал, но это выглядело как очень странное упущение. Даже если URL-кодирование не является стандартом при публикации данных, это соглашение, ожидаемое подавляющим числом серверных служб, и Angular должен поддерживать его из коробки.

ожидается подавляющим числом серверных служб

Перечислим эти сервисы, особенно те, где это единственно возможное решение, а что-то еще сделать просто невозможно

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

Перечислим эти сервисы, особенно те, где это единственно возможное решение, а что-то еще сделать просто невозможно

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

Как я уже упоминал в своем сообщении, в конце концов, мне потребовалась только jQuery $.param чтобы преобразовать мои данные во что-то, что могла бы переварить моя служба (бэкэнд golang).

Однако мне потребовалось очень много времени, прежде чем я смог понять причину, по которой мои формы не отправлялись, и найти этот обходной путь, который я использую в настоящее время. Было бы здорово, если бы Angular мог предоставить внутреннюю функцию, подобную $.param , или, по крайней мере, упомянуть эту проблему и возможные решения на справочной странице API / вики.

Действительно, обходной путь для всего, я никогда не открывал проблему, потому что предполагал, что $ .param был фактическим решением.

Нативная реализация была бы отличной.

У меня точно такая же проблема, php-сервер не принимает метод OPTION изначально, поэтому я предполагаю, что проблема довольно большая.

Я использовал $ http.defaults.headers.post ["Content-Type"] = "application / x-www-form-urlencoded"; для переключения запросов на application / x-www-form-urlencoded для прохождения запроса.

К сожалению, у меня нет jQuery в качестве зависимости, поэтому $ .param не подходит для меня ... есть ли другие обходные пути?

Для этого уже должна быть функция в angular, так как она выполняется для ключа 'params', переданного в $ http ... но он не является общедоступным. Я думаю, это следует изменить и сделать общедоступным, а также следует изменить параметр по умолчанию transformRequest, чтобы сериализовать формы в соответствии с заголовком типа содержимого.

А пока, если вы не хотите повторно реализовывать колесо снова и снова (даже если это всего 5 строк, я согласен, что писать его самому - плохая новость), недавно я увидел хитрый трюк: передать объект FormData как data, no-op transformRequest, чтобы он не преобразовывался в строку как [object FormData] (offtopic, html5 spec wtf, почему нет подходящего toString?), и undefined как заголовок типа содержимого, чтобы XHR.send установил правильные составные заголовки. Для старых браузеров есть полифиллы FormData. Обратите внимание, что запрос становится составным, а не urlencoded, хотя часто это нормально, но для некоторых бэкэндов он все еще может не обрезать его.

+1 Я тоже столкнулся с той же проблемой. Надеюсь, это можно решить с помощью самого Angular?

+1

То же самое ... Я не хочу добавлять jQuery в качестве зависимости только для этого

Невероятно, AngularJS настолько хорош, что я не могу поверить, что этой простой вещи не хватает. Значит, все используют jQuery только для этой функции сериализации?

+1 Довольно безумно, что в такой продвинутой платформе этого нет по умолчанию

+1 Для исправления этого не требуется jQuery, довольно простая функциональность, отправка формы ...

Это действительно должно быть приоритетным для добавления в следующую версию

да, многие API ожидают 'jquery', поэтому эта функциональность обязательна

+1 для angular, чтобы включить это

+1
Другой пользователь здесь ждет этого ...
Мне не нужно включать jquery только для этого ... Этот вопрос должен быть приоритетным!

Для тех, кто пытается найти лучшее решение:
http://victorblog.com/2012/12/20/make-angularjs-http-service-behave-like-jquery-ajax/
(Это работает, и мне не нужно использовать jquery!)

: +1:

Спасибо @ rodrigograca31.

Это отстой. Да ладно, ребята, люди тратят на это часы.

Бьюсь об заклад, большинство просто идут и добавляют JQuery, что смешно, а в моем случае невозможно ...

Просто предупреждаем, это решение отлично работает, если вам нужно только поговорить со Spring Security или чем-то еще с простыми запросами.
http://stackoverflow.com/a/14868725/564449

+1 Итак ... что вы делаете, чтобы это исправить?

+1 возможно, это не стандарт, но x-www-form-urlencoded - наиболее часто используемый формат данных для сообщений AJAX. Я думаю, что по крайней мере AngularJS должен предоставить такую ​​возможность.

Это решение работает для меня
http://bit.ly/1HE96tC

Но я надеюсь, что Angular скоро решит эту проблему.

Это решение работает для меня
http://bit.ly/1HE96tC

Проблема в том, что наиболее распространенным решением этой проблемы является использование $.param , что означает наличие jQuery в качестве зависимости. Я бы предпочел не включать jQuery в мой проект только для сериализации данных для angular.

@UzEE точно, и, более того, везде, где вы ищете ответ, они все одинаковы: используйте jQuery

Вот чего я действительно не могу понять ...

Думаю, я перепишу отдельную версию $ .params ... но было бы намного лучше, если бы мне не пришлось :)

@UzEE и @Avcajaraville не нужно переписывать ... Мое решение (ссылка выше) работает без jquery ...

Я только что узнал об angular, и это обязательная функция!

Теперь (начиная с версии 1.4) это довольно тривиально с $httpParamSerializerJQLike :

.controller('myCtrl', function($http, $httpParamSerializerJQLike) {
    $http({
      method: 'POST',
      url: baseUrl,
      data: $httpParamSerializerJQLike({
        "user":{
          "email":"[email protected]",
          "password":"123456"
        }
      }),
      headers:
        'Content-Type': 'application/x-www-form-urlencoded'
    })
})

Вы также можете переместить эту логику в transformRequest, который выполняет преобразование на основе заголовка. Imo, теперь это правильный баланс между легкостью и гибкостью.

$httpParamSerializerJQLike также можно установить для каждого $http с помощью config.paramSerializer или установить по умолчанию как $httpProvider.defaults.paramSerializer = $httpParamSerializerJQLike

С приведенной выше информацией, я думаю, это можно закрыть.

@lgalfaso речь идет не о сериализации параметров, а о сериализации данных тела. Я считаю, что здесь есть немного работы. Я позабочусь об этом.

Как мне добиться этого с помощью $ resource на 1.3

Только что подошел к этому обсуждению, но я не думаю, что достаточно предоставить $ httpParamSerializerJQLike. Здесь необходимо, чтобы механизм POST понял, что если я скажу, что контент является «application / x-www-form-urlencoded», он автоматически применит преобразование к данным.

Я пытался использовать $httpParamSerializerJQLike в качестве решения проблемы следующим образом:

angular.module('myApp', [])
   .factory('myFactory', ['$http', $httpParamSerializerJQLike,
      function($http , $httpParamSerializerJQLike ) {

         var location = 'https://somelocation.com';
         return {
            check: function(user) {
                return $http({
                    method: 'POST',
                    url: location,
                    data: $httpParamSerializerJQLike(user),
                    headers: {'Content-Type': 'application/x-www-form-urlencoded'}
                });
            }
         };
      }
   ]);

И я получаю эту ошибку $httpParamSerializerJQLike is not defined , возможно, я что-то упускаю.

Использование Angular 1.4.4

@gillchristian : Вам нужны кавычки вокруг первого $ httpParamSerializerJQLike, поэтому:
.factory ('myFactory', ['$ http', '$ httpParamSerializerJQLike',

@AdamMcCormick, спасибо! Я пропустил это

Следующий код работает как шарм для более старой версии

    $httpProvider.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded';
    $httpProvider.defaults.transformRequest.unshift(function(data, headersGetter) {
        var key, result = [],
            response;
        if (typeof data == 'string') {
            response = data;
        } else {
            for (key in data) {
                if (data.hasOwnProperty(key)) {
                    result.push(encodeURIComponent(key) + '=' + encodeURIComponent(data[key]));
                }
            }
            response = result.join('&');
        }
        return response;
    });

Да, @awebdeveloper «работает как шарм» в простых случаях.
это далеко от сериализатора jquery, который также работает для вложенных структур.
и он попадает в категорию «изобретать колесо», с которой я не согласен.

@georgir Параметр paramSerializer доступен с версии 1.4. Вы заметили какие-нибудь баги с ним?

@Narretz Мой предыдущий ответ был направлен специально на @awebdeveloper и его код относительно более старых версий, извините, я не разъяснил это и, возможно, у меня сложилось впечатление, что я критикую текущую версию angular или что-то в этом роде.

Но чтобы ответить вам в любом случае, я не использовал 1.4, но, глядя на код, кажется, что все в порядке. В основном это именно то, что я хотел в своем первом посте по этой проблеме - сделать функциональность, используемую параметром конфигурации $ http "params", более доступной. Теперь пользователи могут называть это своими данными.

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

[И конкретно относительно paramSerializers - отсутствующая функция "JQLike" сериализатора "JQLike" - это способность обрабатывать массив объектов {name, value} для поддержки одного и того же ключа, многократно появляющегося в данных, то есть для таких случаев, как a[]=1&a[]=2&a[]=3 . Это не критичная особенность, и я не уверен, что эта проблема - место для ее обсуждения.]

/ cc @Narretz
Я использую AngularJS 1.4.6.
В разделе конфигурации моего модуля есть следующий код, но он не работает:

$httpProvider.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded;charset=utf-8';
$httpProvider.defaults.paramSerializer = '$httpParamSerializerJQLike';

Также здесь есть безответный вопрос SO.

@armanforghani Я не могу сейчас протестировать, но это должно сработать. Можете ли вы настроить plnkr, который показывает проблему?

@Narretz Пожалуйста, смотрите здесь

@armanforghani , paramSerializers предназначены для сериализации параметров запроса URL, а не полезной нагрузки / данных запроса.
В вашем plnkr нет параметров для сериализации.

Как я могу сериализовать данные для почтового запроса? В настоящее время я использую этот способ . Можете порекомендовать лучший вариант?

Я действительно могу порекомендовать лучший вариант, потому что мне никогда не нужно сериализовать полезную нагрузку, например, jQuery.
Если бы мне пришлось, я бы попробовал https://github.com/angular/angular.js/issues/6039#issuecomment -113502695 в качестве первого варианта.

@armanforghani В документации также есть пример: https://docs.angularjs.org/api/ng/service/ $ httpParamSerializerJQLike Сообщите мне, если это не работает

Это должно быть возможно по умолчанию для всех запросов _post_, вам нужно будет сделать

// Warning, untested code
module.run(function($http, $httpParamSerializerJQLike) {
  $http.defaults.transformRequest.unshift($httpParamSerializerJQLike);
});

@Narretz Я ищу способ установить по умолчанию для всех запросов в конфигурации модуля.
@lgalfaso Спасибо. Интересно, попробую.

@armanforghani, пожалуйста, поделитесь, если это действительно сработало, чтобы другие люди могли использовать тот же механизм, если это именно то поведение, которое они ищут

Я только что протестировал, и он отлично работает. @lgalfaso Большое спасибо.

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

@lgalfaso Я действительно не согласен с тем, что это решает проблему. Существует лишь небольшое подмножество запросов POST, для которых это правильный сериализатор, поэтому добавление его для всех запросов не является хорошим решением для общего случая. Фреймворк должен быть изменен, чтобы использовать этот сериализатор каждый раз, когда типом данных является «application / x-www-form-urlencoded». В противном случае фреймворк отправляет неверные данные

@AdamMcCormick Я считаю, что продолжать обсуждение сериализации данных для запросов _POST_ - это нормально. Это включает в себя то, что должно быть настраиваемым, и должна ли эта конфигурация быть частью ядра или стороннего модуля.
Теперь нет спецификации о том, как следует сериализовать данные JSON. http://www.w3.org/TR/html401/interact/forms.html#h -17.13.4.1 Это означает, что не существует правильного или неправильного способа сериализации. То, что вы считаете правильным, будет другим неправильным.

Способ сериализации данных настраивается, как показано ранее, как это делается, задокументировано https://docs.angularjs.org/api/ng/service/ $ http # transforming-requests-and-answers, и есть несколько инструментов для разных механизмы сериализации.
Текущий механизм позволяет создать преобразование, которое работает по-другому, когда время данных - «application / x-www-form-urlencoded» или что-то еще, поскольку у вас есть доступ к заголовку запроса.

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

При всей этой информации мне непонятно, что следует изменить. Не могли бы вы привести пример чего-то, что невозможно, или для чего потребуется значительное количество LOC?

@ pkozlowski-opensource у вас был план на это, верно? Может быть, вы сможете обрисовать в общих чертах, что бы вы сделали, и я или кто-нибудь другой смогу это сделать?

@Narretz @lgalfaso то, о чем я думал, - это изменить настройки по умолчанию, чтобы, если кто-то установит 'application/x-www-form-urlencoded' в качестве заголовка, мы будем сериализовать его по-другому (не с использованием JSON, а что «большинство людей ожидает»). Очевидно, что это критическое изменение, поэтому его можно сделать только в 1.5.x или 1.6.x.

@lgalfaso, когда я говорю, что хочу данные "application / x-www-form-urlencoded" (сообщая angular тип содержимого), он вообще не должен отправлять JSON! Он должен отправлять объект данных, который я предоставляю, как если бы это была форма WWW (как четко указано в спецификации), как я ему говорю. Я не уверен, почему это так сложно понять. Текущее поведение не соответствует спецификации и, следовательно, неверно, поэтому ломается или нет, оно должно измениться. Дело не в том, что я думаю, и не имеет значения, есть ли обходной путь. @ pkozlowski-opensource несколько раз заявлял, как можно реализовать решение, и я говорю, что так и должно быть.

@AdamMcCormick , можно ли узнать, о каком стандарте вы говорите?
https://xhr.spec.whatwg.org/#the -send () - метод является стандартным для _xhr_, что и составляет $http abstracts. Здесь, как следует сериализовать тело, указано только для двух случаев; документ HTML или строка.

@lgalfaso вы связали спецификацию для "application / x-www-form-urlencoded" выше, и довольно ясно, как пары ключ / значение должны быть сериализованы и отправлены. Когда тип контента - «application / x-www-form-urlencoded», весь смысл состоит в том, чтобы имитировать способ, которым бы выглядела HTML-форма, если бы вы ее использовали POST. Это не «тело», это WWW-форма в кодировке URL, она должна действовать как она.

@AdamMcCormick, спецификация на http://www.w3.org/TR/html401/interact/forms.html#h -17.13.4.1 применяется только к <form> и было бы разумно думать, что это также должно применяются к объектам FormData , но там нет ничего, что применимо к объектам JSON. По крайней мере, ничего из того, что мне удалось найти. Если есть спецификация, которая определяет это, опубликуйте ее здесь, поскольку это будет веской причиной для оправдания критического изменения. Если нет, то лучше иметь настраиваемую опцию для сериализатора, но оставить текущий сериализатор по умолчанию.

@lgalfaso Это НЕ ОБЪЕКТ JSON. Это объект JavaScript, который я пытаюсь использовать для замены FORM. «application / x-www-form-urlencoded» - это формат данных, а не «application / json». Вы смешиваете эти две вещи и поэтому, кажется, меня не слышите. http://www.w3.org/TR/html401/interact/forms.html#h -17.13.4.1 определяет, каким ЛЮБЫМ данным, передаваемым с типом содержимого "application / x-www-form-urlencoded", ДОЛЖНЫ соответствовать. Это «веская причина для оправдания критического изменения». Что может быть более убедительным, чем явная неправильность текущего режима работы?

TL, DR:
В документации должно быть указано поведение $http при сериализации двоичных данных, какова сериализация по умолчанию и какие сериализации доступны, если они выходят за рамки значения по умолчанию.
На мой взгляд, наилучшее поведение заключается в том, что методы angular, которые приводят к HTTP-запросу, должны использовать заголовок _configuration_ ИЛИ _content-type_, чтобы решить, какой алгоритм они будут использовать для сериализации двоичных данных. Кроме того, если следовать маршруту конфигурации, Angular должен установить правильный тип содержимого для выбранной сериализации.

Теперь нет спецификации о том, как следует сериализовать данные JSON.

JSON - это сериализация , нет необходимости снова сериализовать ее. :ухмылка:
Это указано в RFC @ IETF и на json.org .

application / x-www-form-urlencoded - еще одна сериализация, указанная как часть спецификаций HTML.

Ожидается, что параметр data из функции $http получит любой из двух типов данных:
String : данные в текстовом формате, это может быть текстовая строка или сериализованный другой тип данных, если необходимо
Object : двоичный объект, который будет сериализован либо Angular, либо пользовательским агентом перед отправкой через HTTP. Мы уже знаем, что Angular по умолчанию сериализует его как JSON и игнорирует заголовок типа содержимого, если он установлен.

Почему это похоже на ошибку?
В документации $ http. [post | get | put | ...] не указывается метод сериализации по умолчанию, используемый Angular, когда параметр "data" является объектом javascript и не ведет себя как самые популярные фреймворки javascript (jQuery, Mootools, ...). Также он ведет себя так, как по умолчанию ожидают самые популярные серверные технологии (PHP, Java, ASP.net, ...)

Кроме того, в документации также не говорится, что $ http будет игнорировать «Content-type» и любой другой заголовок параметра, чтобы решить, какой метод сериализации он будет использовать.

Это один из вариантов использования, который приводит людей к этой проблеме с github.
Используя PHP-сервер и Angular без jQuery (который бесполезен для приложения Angular) в первый раз (как и я), вы почти всегда будете пытаться:
$http.post(url, jsObject).then(...)
Это не удастся, PHP по умолчанию десериализует x-www-form-urlencoded data в переменную $_POST , а не json data.
Просматривая сетевой инспектор в firebug, chrome или стрекозе, вы можете заметить, что данные были сериализованы в JSON. Ничего страшного:
Просмотрите свой код, прочтите документацию по Angular. Ничего плохого не найду.
Ожидая, что angular будет автоматически сериализовать двоичные данные в наиболее распространенную сериализацию в HTTP, вы помните несколько других случаев, когда вам нужно было явно установить тип данных как x-www-form-urlencoded , попытаться установить заголовок http и надеяться, что фреймворк соблюдает Это:
$http.post(url, jsObject, {headers: {'Content-Type': 'application/x-www-form-urlencoded'}}).then(...)

Когда это не удастся, вы подумаете, что вы или фреймворк сделали что-то не так, и снова прочитаете документы, поспрашиваете, ищите в Интернете, ...

Где-то рядом с этим вы узнаете о $httpParamSerializer и, возможно, воспользуетесь им, перейдя на страницу

@ribeirobreno Полностью согласен. Это было моей проблемой при работе с angular 1 и после прохождения именно этих шагов и необходимости использовать $ .param, потому что я не узнал о $ httpParamSerializer. После всего этого я столкнулся с той же проблемой с Angular 2, и теперь мой день снова пролетает незаметно, пока я пытаюсь понять, как это сделать без повторного использования jquery, поскольку мне не удалось найти $ httpParamSerializer. Что меня интересует еще больше, так это то, что бэкэнд-фреймворки используют ребята из angular, чтобы не приходить к этой проблеме немедленно, так как я столкнулся с этим как с Flask, так и с ASP.Net, и оба парня, выполняющие бэкэнд, сказали, что это моя проблема

@DominikDitoIvosevic Сегодня я просмотрел документы и нашел это: https://docs.angularjs.org/api/ng/service/ $ http # default-transformations

Не знаю, пропустил ли я его раньше или он был добавлен ... в любом случае, я думаю, было бы действительно неплохо иметь ссылку на «преобразования по умолчанию» рядом с параметрами данных здесь: https: // docs. angularjs.org/api/ng/service/ $ http # использование

Я понимаю, что прихожу к этому очень (очень) поздно, но, как новичок в Angular, я поражен тем, как неловко получить тело сообщения www-form-urlencoded . Я был очень удивлен, что это _не_ значение по умолчанию, учитывая (как мастерски сказал

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

Как новичок в Angular! Помогло мне в 2017 году :)

я столкнулся с этой проблемой в angular2
поэтому я использовал этот код здесь
http://stackoverflow.com/questions/35212341/angular2-http-post-request-parameters