Angular.js: encodeUriSegment в параметрах кодирования ресурса, должен быть необязательным.

Создал гист с изменениями для угона :) https://gist.github.com/3749345

+1 к этому. Обеспечивает большую гибкость. В нашем случае использования мы используем весенний остаток данных для серверной части, а методы поиска — это параметры пути, которые нам нужно сопоставить с действиями, в идеале в том же объекте ресурса, что и для основных операций CRUD.

+1. Наши идентификаторы содержат косую черту (мы используем RavenDB), и это было бы чистое решение, если бы оно не было закодировано.

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

Не рекомендуется кодировать URI. Не делать этого сейчас может показаться «чистым», но я уверяю вас, что это укусит вас за задницу в этой жизни или в следующей.

Если я правильно прочитал http://www.ietf.org/rfc/rfc3986.txt , нам должна быть разрешена незакодированная косая черта для фрагмента.

3.5. Фрагмент

Компонент идентификатора фрагмента URI позволяет косвенно
идентификация вторичного ресурса по ссылке на первичный
ресурсы и дополнительную идентифицирующую информацию. Идентифицированный
вторичный ресурс может быть частью или подмножеством первичного
ресурс, некоторое представление о представлениях основного ресурса или
некоторый другой ресурс, определенный или описанный этими представлениями. А
Компонент идентификатора фрагмента обозначается наличием
знак числа ("#") и завершается концом URI.

 fragment    = *( pchar / "/" / "?" )

...
Символы косой черты ("/") и вопросительного знака ("?") разрешены.
представляют данные внутри идентификатора фрагмента. Остерегайтесь, что некоторые
более старые ошибочные реализации могут неправильно обрабатывать эти данные
когда он используется в качестве базового URI для относительных ссылок (раздел
5.1).

Вариант использования: $location.hash('/secondary-resource')

Мне просто любопытно, можно ли избежать этой проблемы, дважды закодировав параметры?

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

'/', '%252F' --> %25252F

Также,

/ %2f --> %252F
'/', '//' --> %2F%2F

Спасибо за мысль. Запрос остается в силе.

Столкнулся с этим сегодня. +1
Мне может это не нравиться, но наши идентификаторы тоже содержат косые черты. Это должно быть необязательным.

+1

+1

+1

+1

+1

+1

Я вижу упоминание о базе данных (RavenDB), которая делает текущую реализацию проблематичной, но я ожидаю, что будет промежуточный сервер, который ожидает закодированные компоненты и декодирует их в правильный идентификатор на бэкэнде. Может ли кто-нибудь предоставить более конкретный вариант использования, когда принудительное кодирование вызывает проблемы (извините, у меня нет большего контекста в RavenDB)?

Мы не решаемся разрешить это с текущим дизайном $resource, потому что ввод пользователя может легко повлиять на путь запроса.

Я использую $location для дизайна REST/гипермедиа, а не RavenDB (или $resource). Мне приходилось работать с пропатченной версией библиотеки.

Я также ищу подтверждение того, что на самом деле это предложение действительно соответствует RFC - см. мой комментарий выше .

Я также могу быть немного заржавевшим в библиотеке — так что большие извинения, если я ошибаюсь — есть также две реализации: одна в ресурсе на L332 и одна в Angular на 1071 .

Мне просто нужен тот, что в Angular, потому что он используется $location ;-) (да, я вижу здесь проблему, поэтому я бы не советовал иметь разные реализации). Извините, если у меня есть какие-то неправильные анализы.

+1
У кого-нибудь есть обходной путь для создания URL-адресов ресурсов, содержащих косую черту?

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

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

Привет,

у меня та же проблема, но суть не работает для меня. где я должен разместить этот метод encodeUirSegment или где я могу разместить эту опцию? :/

Я использовал перехватчик HTTP для преобразования URL-адресов. Он работал, пока я не протестировал IE11. Угловые разрывы запросов XHR к URL-адресам, включая % в IE11. Не уверен насчет IE10. Предполагается, что Angular поддерживает IE9+ ( ссылка )

Думаю, я вернусь к модифицированному ngResource..

@connorbode --- чувак, как это было упомянуто в твоей проблеме, напиши неудачный тестовый пример =) Этот путь ДОЛЖЕН быть уже пройден, так что есть две возможности: либо он не пройден и должен быть пройден, либо ты делаешь что-то, чтобы сломаться это.

Давайте узнаем, что это такое!

+1

+1

+1

Невозможно работать с CouchDB и дизайн-документами (_design/cafehub/_view/menu_items)

Не могли бы вы добавить +1 к моему запросу на вытягивание вместо этой проблемы? Он устраняет проблему, но обычно игнорируется с момента его отправки. https://github.com/angular/angular.js/pull/7940

+1
Это действительно нужно для взаимодействия с некоторыми устаревшими веб-сервисами, которые не выполняют декодирование URL.

+1

Определенно существуют жизнеспособные и полезные обстоятельства, когда пользователь захочет отключить кодировку параметров URL (например, когда вы хотите добавить к базовому URL путь к ресурсу).

+1

+1

+1

+1

@toddb просто к вашему сведению, ваша спецификация относится к части фрагмента URL-адреса, то есть к части #foo/bar , где экранирование косой черты действительно не требуется или не подходит. Но эта ошибка связана с экранированием косой черты в основной части URL-адреса. В общем, я не думаю, что RFC применим к этому, то, как служба Angular $resource обрабатывает сопоставление с образцом и построение URL, действительно не сильно касается RFC.

Отсутствие экранирования косой черты в обычном параметре стиля :param приводит к проблеме, заключающейся в том, что шаблон становится необратимым. Например, если у вас есть /x/:param , и вы разрешаете генерировать /x/y/z для {param: 'y/z'} , результирующий /x/y/z не сможет проанализировать шаблон URL.

ИМХО, может иметь смысл иметь функцию в шаблонах URL-адресов, чтобы принимать шаблон звезды, который ест косые черты, например, "/:param1/:param2/*pathParam" , где *pathParam съедает косые черты в URL-адресе. Для параметров * тогда имеет смысл также принимать косые черты, не экранируя их.

@mprost - вы совершенно правы, что я регистрировал ошибку только вокруг фрагмента. Код, который я использую, _также_ влияет на фрагмент. Я использую не сервис $resource , а $location . Если мне не изменяет память, есть пара реализаций кода uriSegment.

Патч @connorbode из быстрого чтения решит проблему. Ваше здоровье

+1

+1

+1

+1

+1

+1

+1

+1

Вы можете использовать тот же синтаксис, что и в ui-router lib:
http://angular-ui.github.io/ui-router/site/#/api/ui.router.util.type:UrlMatcher

+1

это также происходит в месте

:+1:

+1

В настоящее время я делаю декодирование, чтобы отправить исходный URL-адрес на серверную часть.

.factory('decodeUriSegment', () => {
    return (url) => {
      return url.replace(/@/g, '%40')
        .replace(/:/g, '%3A')
        .replace(/\$/g, '%24')
        .replace(/,/g, '%2C')
        .replace(/\+/g, '%20');
    };
  });

+1

+1

app.config(function($resourceProvider) {
    $resourceProvider.defaults.stripTrailingSlashes = false;
});

https://github.com/angular/angular.js/pull/5560

+1

я получаю эту ошибку в службе ресурсов angularjs $
Ошибка: encodeUriSegment не является функцией

@ibrahim89 ibrahim89 , убедитесь, что вы используете одну и ту же версию angular и angular-resource.

@gkalpak , спасибо!!

моя ошибка решена