Как передать слэш и другие "чувствительные к URL" символы службе REST WCF?
У меня есть служба REST WCF, которая имеет метод, который получает параметр в виде строки. Эта строка может содержать косую черту / символ. Это делает мой запрос неправильным, так как я думаю, что URL идет не так.
При запросе и получении ответа (WebRequest.GetResponse()) выдается "Удаленный сервер возвращает ошибку: (400) Bad Request". исключение.
Моя просьба: http://localhost:17679/testmethod/DmC/TCGlOLz1EbEwqAls5Q==\ nh2cQzTizSBg =
Я пытался использовать Uri.EscapeDataString, но это не помогает, я получаю то же исключение, что и выше. После этого преобразования мой запрос выглядит следующим образом: http://localhost:17679/testmethod/DmC%2FTCGlOLz1EbEwqAls5Q%3D%3D%0Ah2cQzTizSBg%3D
Если я передаю строку без косой черты в строке, она работает так, как я хочу.
Как передать слэш и другие "чувствительные к URL" символы службе REST WCF?
Спасибо.
ОБНОВЛЕНИЕ: Я решил это, вы можете увидеть это в моем ответе ниже.
3 ответа
Я решил это.
Шаблон URI является ключом.
Если я определю URI таким образом, он выдаст исключение выше:
[OperationContract()]
[WebGet(UriTemplate = "/testmethod/{testvalue}"/*, BodyStyle = WebMessageBodyStyle.Bare, ResponseFormat = WebMessageFormat.Xml*/)]
string TestMethod(string testvalue);
Изменяя этот способ, он работает:
[OperationContract()]
[WebGet(UriTemplate = "/testmethod?v={testvalue}"/*, BodyStyle = WebMessageBodyStyle.Bare, ResponseFormat = WebMessageFormat.Xml*/)]
string TestMethod(string testvalue);
В любом случае, Uri.EscapeDataString необходим!
Хотя принятый ответ будет работать в некоторых случаях, когда параметр URI находится в конце URI, он не будет работать, если параметр URI находится в середине URI. Но с помощью нескольких параметров конфигурации вы можете разрешить приложению принимать закодированные косые черты.
HttpListener
который принимает входящие запросы использует внутренний HttpListenerRequestUriBuilder
проанализировать необработанный URI запроса.
HttpListenerRequestUriBuilder
будет или не будет удалять кодировку, основанную на настройке. Добавьте следующую настройку к вашему app.config
файл:
<configuration>
<system.net>
<settings>
<httpListener unescapeRequestUrl="false"/>
</settings>
</system.net>
</configuration>
Это позволит входящим Message
"s To
заголовки должны быть правильно построены без удаления URI.
Если вы используете версию.NET до 4.5, я полагаю, что вам также может понадобиться добавить другой параметр, инструктирующий System.Uri
класс, чтобы не избежать косых черт для http
а также https
пути. Этот параметр выглядит следующим образом:
<configuration>
<uri>
<schemeSettings>
<add name="http" genericUriParserOptions="DontUnescapePathDotsAndSlashes"/>
<add name="https" genericUriParserOptions="DontUnescapePathDotsAndSlashes"/>
</schemeSettings>
</uri>
</configuration>
Uri.Match
и по умолчанию QueryStringConverter
должен по-прежнему работать с неэкранированным текстом, поэтому такой метод:
[WebGet(UriTemplate = "foos/{bar}/baz"]
public Baz GetFooBaz(string bar)
{
// ...
}
предоставит неэкранированную строку bar
параметр.
Попробуйте форсировать \ перед каждым /. (обычно это заставляет метасимволы быть прочитанными как нормальный символ)