Restsharp: порт удаляется из заголовка хоста

Есть ли способ воспроизвести это в простом тесте?

https://github.com/poornas/restsharp-test — это проект с голыми костями, использующий restsharp для выполнения вызова корзин списка на сервер minio. Он использует собственный аутентификатор — вы увидите, что он не работает из-за несоответствия подписи. как только запрос передается в restsharp, порт отключается, прежде чем он будет передан на сервер.

Спасибо. Я посмотрю и постараюсь исправить.

Спасибо!

@alexeyzimarev Есть идеи, что может быть причиной этого?

@alexeyzimarev , у вас уже была возможность изучить это? Спасибо

Проверка сейчас

Я клонировал вашу реплику и вижу это:

  "parameters": [
...
    {
      "name": "Host",
      "value": "play.minio.io:9000",
      "type": "HttpHeader"
    }

Вы имеете в виду, что параметры в запросе в порядке, но значение не отправляется на сервер должным образом?

@alexeyzimarev , это правильно - трассировка, которую вы видите выше, идет до вызова executeAsync. Когда вызывается ExecuteAsync, Restsharp вызывает метод Authenticate, где мы устанавливаем заголовок авторизации подписи на основе url:port в пользовательском аутентификаторе. порт, похоже, был удален Restsharp перед попаданием на сервер и после вызова Authenticate().

Есть новости по этому поводу? Мы довольно сильно заблокированы в этом.

Жаль, что я не мог пока посмотреть на это. Если это очень критично, может быть, вы, ребята, можете потратить час на отладку?

Я быстро рассмотрел это. Насколько я могу судить, проблема здесь на самом деле не с RestSharp, а на самом деле HttpWebRequest в System.Net !

К тому времени, когда RestSharp передаст запрос в System.Net, свойство Host (Uri) в HttpWebRequest все еще содержит информацию о порте. Однако при вызове .SendRequest() используемый заголовок Host заполняется только хостом URI, а не хостом и портом .

Вот скриншот моего отладчика по ссылке выше.

Это явно противоречит спецификации HTTP , которая учитывает использование портов.

Кто-нибудь, пожалуйста, поправьте меня, если я ошибаюсь, потому что я никогда не находил бага в фреймворке dotnet, а обычно, когда я думаю, что нашел, — нет. В противном случае я полагаю, что следующими шагами будет поднятие этой проблемы в репозитории CoreFX?

Поднимем!

Сделано - давайте посмотрим, законно ли это, где ошибка или нет.

Просто любопытно - кто-нибудь знает, является ли это регрессом с недавним .NET Core? (2.1) Или с последней стабильной (2.0)? Или отличие .NET Framework от .NET Core, или отличие ОС Windows от Linux? («не знаю» — хороший ответ, спасибо!)

@karelz TBH Я изучил эту проблему, чтобы решить другую проблему, чтобы я мог перестать получать предупреждения компилятора 😆 для меня это «не знаю», я пробовал это только на .NET Core 2.0 на MacOS. Эта библиотека только недавно (может быть, несколько месяцев) была обновлена ​​для поддержки .NET Core, а не только .NET Framework. Может, @alexeyzimarev знает больше?

Хорошо, по крайней мере, вы знаете: он работает на .NET Framework (Windows) и не работает на .NET Core 2.0 (Mac). Это правильное резюме?

Нет - из других тем, в которых я участвую, я бы сказал, что это не работает на всех платформах на .NET Core 2.0, и я не знаю о .NET Framework.

@karelz Я бы сказал, что это предположение было бы правильным. Я только что перешел с полного фреймворка на .net core/standard, а потом тесты сломались. Я не уверен, что это регрессия от 1.x, поскольку мы только пытались перейти на .net Standard 2.0.

@niemyjski спасибо за подтверждение. Это достаточная информация на данный момент. Я просто изучал известные факты/опыт.

Мы оставляем этот вопрос открытым?

Исправление в CoreFx есть в PR: https://github.com/dotnet/corefx/pull/28375

Да :)

Спасибо
-Блейк Нимийски

В четверг, 22 марта 2018 г., в 15:57, Цезарь Чен, [email protected]
написал:

Исправление в CoreFx находится в PR: dotnet/corefx#28375.
https://github.com/dotnet/corefx/pull/28375

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375454963 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AA-So67a2QfPq72jMHNxaSCBhDXiWXOMks5thBAygaJpZM4SOXLx
.

Была ли какая-то причина, по которой мы не могли переключиться на HttpClient, который намного быстрее?
и легче работать? Этой проблемы не будет?

Спасибо
-Блейк Нимийски

В пятницу, 23 марта 2018 г., в 7:14, Блейк Ниемийски [email protected]
написал:

Да :)

Спасибо
-Блейк Нимийски

В четверг, 22 марта 2018 г., в 15:57, Цезарь Чен, [email protected]
написал:

Исправление в CoreFx находится в PR: dotnet/corefx#28375.
https://github.com/dotnet/corefx/pull/28375

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375454963 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AA-So67a2QfPq72jMHNxaSCBhDXiWXOMks5thBAygaJpZM4SOXLx
.

@niemyjski , вы имеете в виду, что переключатель RestSharp использует HttpClient вместо HttpWebRequest ?

Да :)

Спасибо
-Блейк Нимийски

В пт, 23 марта 2018 г., в 9:22, Алексей Зимарев [email protected]
написал:

@niemyjski https://github.com/niemyjski вы имеете в виду, что вы переключаетесь
RestSharp использует HttpClient вместо HttpWebRequest?

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375680769 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AA-So0cbK66_Nq-MRdk0xwdb7sLPSGUoks5thQUUgaJpZM4SOXLx
.

@niemyjski вопрос был один _или_ другой, _yes_ действительно неправильный ответ :)

Если вы имеете в виду, что RestSharp должен использовать HttpClient - я за это, но в прошлый раз, когда я пытался, было много работы, чтобы сопоставить все параметры в RestClient.

Да, мы должны переключиться на HttpClient, который гораздо более гибкий, имеет лучшую производительность и современный API, который, как мы знаем, работает везде. Мы могли бы внести некоторые критические изменения и поднять основные :)

Да, я хорошо делаю это, но я не делаю это в одиночку. Я пытался, и это было слишком много работы. Я бы также удалил асинхронные вызовы, которые принимают обратные вызовы. ContinueWith должен быть в порядке.

Похоже, это было объединено с 2.1, должны ли мы выпускать ночную версию, которая ссылается на новый предварительный просмотр 2 бит, и мы можем перемещать другие пакеты на долгое время? Есть ли какие-то обходные пути, которые мы можем сделать для сред выполнения/библиотек < 2.1?

Я понятия не имею об обходных путях

Мне нужно сначала сделать выпуск, прежде чем я смогу изменить предварительный выпуск на предварительную версию 2.1.

Это было решено? Пакеты RTM 2.1 находятся на nuget.

Итак, вам нужно попробовать использовать 2.1 и посмотреть, исправили ли они это?

@niemyjski мой комментарий от 20 апреля глупый. Мне не нужно ничего никуда указывать. Библиотека компилируется в .NET Standard 2.0. Ошибка вызвана ошибкой в ​​среде выполнения .NET Core 2.0, поэтому, как только вы перестроите свое приложение с помощью .NET Core 2.1, если проблема устранена, оно должно начать работать. Извините за путаницу.