2011-01-25 10 views
1

У меня есть api для отдыха, который используется через JSONP из-за проблем с перекрестным доменом, я выполнил ошибку, который улавливает каждую ошибку, которая происходит на странице и сообщения это на сервер Ури для регистратора ошибок что-то вроде:Rest API: передача window.location.href в REST uri

user/{userId}/message/{errorMessage}/browser/{browser}/browserVer/{browserVer}/secure/{secure}/os/{os}/location/{location}" 

переменного расположения проблематично, как я могу передать window.location.href в Ури?

Я попробовал escape, encodeuri, encodeuricomponent, мне нужно, чтобы base64 это? благодаря

ответ

0

Спасаясь последовательность для URI, определен в section 2.4.1 из RFC2396 (унифицированные идентификаторы ресурсов):

An escaped octet is encoded as a character triplet, consisting of the 
percent character "%" followed by the two hexadecimal digits 
representing the octet code. For example, "%20" is the escaped 
encoding for the US-ASCII space character. 

    escaped  = "%" hex hex 
    hex   = digit | "A" | "B" | "C" | "D" | "E" | "F" | 
         "a" | "b" | "c" | "d" | "e" | "f" 

Этот документ также определяет зарезервированные символы для path компонента в section 3.3:

Within a path segment, the characters "/", ";", "=", and "?" are reserved. 

Так вам необходимо использовать encodeURIComponent(), так как escape() был deprecated и encodeURI()does not escape all reserved characters, которые должны быть экранированы в соответствии с выдержкой RFC выше.

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

>>> escape('//'); 
"//" 

>>> encodeURI('//'); 
"//" 

>>> encodeURIComponent('//'); 
"%2F%2F" 

Однако обратите внимание, что, если это возможно, вы должны использовать POST вместо GET. Это правильный метод для использования в REST (и вообще), поскольку вы отправляете данные от клиента на сервер (POST), а не получаете их с сервера (GET).

Использование POST также позволит избежать дополнительной проблемы. Поскольку длина URI ограничена на общих веб-серверах, рано или поздно вы столкнетесь с запросом с очень длинным URI, который либо обрезается, либо генерирует ошибку. Переключение на POST позволит вам сохранить URI в чистоте и сохранить данные в теле сообщения вместо URI. См. answers to this question для получения информации о ограничениях длины URI.

+0

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

+0

О, я вижу (JSONP). Удаление символов - это, конечно, хороший вариант, если позже вам не понадобится восстанавливать URI. Тем не менее, если ваш API позволяет это, вам может потребоваться переместить параметры из компонента пути в строку запроса - это поможет вам избежать ограничения длины URI. Мы столкнулись с этим в одном проекте, у него не было хорошего опыта: -/ Обратите внимание, что вам все равно понадобится 'encodeURIComponent()' для альтернативной строки запроса, поскольку значения {location} имеют свои собственные параметры запроса может нарушить запрос (по той же причине, что и сейчас). – MicE

+0

спасибо за отзыв о строке запроса, я закончил использование base64 для параметра location, поскольку я не хотел начинать с определенных символов. – Amnon