Как передать слэш и другие "чувствительные к 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 параметр.

Попробуйте форсировать \ перед каждым /. (обычно это заставляет метасимволы быть прочитанными как нормальный символ)

Другие вопросы по тегам