Как передать слэш и другие «чувствительные к URL» символы службе REST WCF?

Question

У меня есть служба 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?

Thx.

ОБНОВЛЕНИЕ: Я решил это, вы можете увидеть это в моем ответе ниже.

Answer 1

Я решил это.

Шаблон 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 необходим!

Answer 2

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

HttpListener, который принимает входящие запросы, использует внутренний HttpListenerRequestUriBuilder для анализа необработанного URI запроса.

HttpListenerRequestUriBuilder будет или не будет удалять кодировку, основанную на настройке. Добавьте следующий параметр в ваш файл app.config:

<configuration>
  <system.net>
    <settings>
      <httpListener unescapeRequestUrl="false"/>
    </settings>
  </system.net>
</configuration>

Это позволит правильно формировать входящие Message заголовки 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.

Answer 3

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