Работа с двойной кодировкой в ​​Flurl http запросов на получение - PullRequest
Новая
       14

Работа с двойной кодировкой в ​​Flurl http запросов на получение

0 голосов
/ 10 октября 2018

У меня возникли проблемы с пониманием того, как передавать закодированные данные в запросе с использованием flurl.У нас есть API, который выглядит следующим образом: 

https://servicename.com/domain/api/{identifier}?parameter=value

И в некоторых конкретных случаях у нас есть идентификаторы, которые содержат косую черту /

Мы создаем запрос, используя следующий код: 

var clientRequest = this.configuration.Client
            .Request(this.configuration.RequestPath)
            .AppendPathSegment(identifier)
            .WithHeader("Requesting-System", "api");

И мы называем это используя: 

using (var response = await clientRequest.GetAsync(cancellationToken))
{
    return await response.Content.ReadAsStringAsync();
}

Сейчас.Принятие простого подхода - просто передать идентификатор с косой чертой;скажем, ABC / 123.Приведенный выше код генерирует clientRequest с путем 

https://servicename.com/domain/api/abc/123?parameter=value

, который, как ожидается, завершается с ошибкой 400.Таким образом, решение для этого, основанное на наших спецификациях API, состоит в том, чтобы закодировать косую черту в виде% 2F и передать ее в URL.К счастью, Flurl делает это довольно легко в теории, допуская необязательный параметр в методе AppendPathSegment, который вызывает кодировку.Поэтому мы изменим вышеприведенное, чтобы использовать 

.AppendPathSegment(identifier, true)

, который генерирует clientRequest с путем 

https://servicename.com/domain/api/abc%2F123?parameter=value

Именно то, что я ожидал бы увидеть.Если я обращаюсь к этому URL-адресу с помощью почтальона, то я вижу правильный ответ, который я ожидаю от API.

Однако, когда я вызываю его с помощью метода GetAsync (так же, как и выше), я все равнополучить ошибку 400 Подресурс не распознана;и в моих журналах я вижу, что фактический запрос был сделан на 

https://servicename.com/domain/api/abc/123?parameter=value

Есть ли точка во время вызова службы, что Flurl декодирует строку URL?Если это так, как я могу передать% 2F?

Попробовал двойное кодирование, чтобы запрос содержал идентификатор abc% 252F123.Учитывая вышесказанное, я ожидал, что это будет декодировано в abc% 2F123, который затем будет отправлен нашему API.Но в этом случае декодирование не происходит, и URL-адрес запроса: 

https://servicename.com/domain/api/abc%252F123?parameter=value

Заранее большое спасибо за помощь.

1 Ответ

0 голосов
/ 12 октября 2018

Похоже, что это ошибка или ошибка (в зависимости от того, кого вы спрашиваете) с System.Uri, который HttpClient использует глубоко в стеке вызовов.Чтобы обойти это, добавьте это в app.config или web.config: 

<uri>
  <schemeSettings>
    <add name="http" genericUriParserOptions="DontUnescapePathDotsAndSlashes" />
  </schemeSettings>
</uri>

Весь кредит для этого идет в этот ответ .

Если вообщевозможно, я бы вообще не допустил зарезервированных символов URL в ваших идентификаторах.Кажется, это просто причуда.Если это невозможно, возможно, придумайте свою собственную escape-последовательность для представления прямой косой черты.

...