Nano Hash - криптовалюты, майнинг, программирование

Ruby rest-client Accept Проблема с заголовком

Я экспериментировал с драгоценным камнем Ruby rest-client и столкнулся с "проблемой", чтобы говорить. Я заметил, что когда я нажимал определенный URL-адрес, который должен просто возвращать HTML, я получал ошибку 404, если специально не указывал:

RestClient.get('http://www.example.com/path/path', accept: 'text/html')

Однако практически любая другая страница, на которую я попаду без явного указания заголовка Accept, прекрасно вернет HTML.

Я посмотрел исходный код объекта Request, расположенный здесь. и в методе default_headers вокруг строки 486 видно, что заголовок Accept по умолчанию равен */*. Я также нашел соответствующий запрос на вытягивание здесь.

Я не совсем понимаю, почему на конкретном сайте (не на всех) я должен явно указывать Accept: text/html, когда любой другой сайт, возвращающий HTML по умолчанию, делает это без дополнительной работы. Я должен отметить, что другие страницы на этом же сайте работают нормально при запросе страницы без явного указания text/html.

Это не большая проблема, и я могу легко обойти ее, используя text/html, но я просто подумал, что это немного странно.

Я должен также отметить, что когда я использую другой клиент REST, например, встроенный в IntelliJ, и указываю Accept: */*, он возвращает HTML без проблем...

РЕДАКТИРОВАТЬ: Хорошо, это немного странно... когда я делаю это:

RestClient.get('http://www.example.com/path/path', accept: '*/*')

Затем он возвращает HTML, как я и ожидал, но отключение этого параметра accept: */* не работает, хотя по умолчанию этот заголовок должен быть */* в соответствии с исходным кодом...

Интересно, поскольку в моем URL-адресе есть /path/path, RestClient думает, что это конечная точка для какого-то API, поэтому вместо этого пытается получить XML...

РЕДАКТИРОВАТЬ 2: Немного поэкспериментировать... Мне удалось передать блок в запрос GET следующим образом:

RestClient.get('http://example.com/path/path') {
    |response, request, result|

    puts response.code
    puts request.processed_headers
}

И я получаю ошибку 404, и возвращается processed_headers:

{"Accept"=>"*/*; q=0.5, application/xml", "Accept-Encoding"=>"gzip, deflate"}

Тело ответа выглядит следующим образом:

<?xml version="1.0" encoding="UTF-8"?>
<hash>
  <errors>Not Found</errors>
</hash> 

Итак, он отправляет заголовок */*, но по какой-то причине кажется, что application/xml имеет приоритет. Может быть, это просто что-то на стороне сервера и не под моим контролем? Думаю, я просто не уверен, как это application/xml вообще добавляется в заголовок Accept. Я не могу найти ничего, просматривая исходный код.


  • Можете ли вы сказать, какой код ошибки для этого конкретного запроса? 24.11.2015
  • Да, это дает мне 404. Я смог передать блок в запрос GET, и заголовок Accept, который он отправляет, выглядит следующим образом: {"Accept"=>"*/*; q=0.5, application/xml" ... Если я явно укажу ему принимать только */*, он работает, как я упоминал в моем редактировании , я не совсем понимаю, почему XML имеет приоритет, когда на других страницах того же сайта тот же заголовок (или его отсутствие) работает нормально... 24.11.2015
  • Более конкретные поля имеют более высокий приоритет, чем поля с рядом возможностей. Таким образом, здесь xml/application получает больший приоритет. Вы можете узнать больше о принятии здесь 24.11.2015
  • @ r2_d2 Имеет смысл, я просто не уверен, как именно это поле application/xml вообще помещается в заголовок Accept ... Я нигде не могу найти его в источнике. Из того, что я вижу, это должно быть просто */*, но где-то по пути добавляется q=0.5, application/xml. 24.11.2015
  • но остальной клиент по какой-то причине отправляет этот заголовок. Куда указывает URL? 24.11.2015
  • @ r2_d2 Это просто указывает на обычный веб-сайт. Никаких странных конечных точек API или чего-то подобного. Я открыл вопрос на Github об этом. Тот PR, на который я ссылался, должен был исправить это, и, согласно источнику на Github, он должен просто пройти */*, но по какой-то причине у меня, похоже, старое поведение, хотя я нахожусь на текущем камне. Может быть, я просто пропустил что-то действительно очевидное здесь... 24.11.2015
  • что вы подразумеваете под старым поведением? 24.11.2015
  • @ r2_d2 Старое поведение отправляло */*;q=0.5 application/xml в заголовке Accept. Кто-то сделал пиар, который изменил его на просто */*. Я действительно понял проблему. Я установил версию кандидата на выпуск (2.0.0rc2), и проблема устранена. 24.11.2015

Ответы:


1

Нашел "проблему". Похоже, что PR, о котором я упоминал в своем исходном посте, на самом деле не был выпущен до rest-client2.0.0.rc1, который все еще является кандидатом на выпуск, поэтому на самом деле он еще не вышел или, по крайней мере, не может быть получен через мой gem update rest-client.

Я использовал следующую команду для установки 2.0.0rc2:

gem install rest-client -v 2.0.0.rc2 --pre

Затем сослался на него в моем коде, и теперь он работает:

@request = RestClient::Request.new(:method => :get, :url => 'http://some/resource')
puts @request.default_headers[:accept]

Печатает...

*/*

Как и ожидалось сейчас.

24.11.2015
Новые материалы

Кластеризация: более глубокий взгляд
Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

Как написать эффективное резюме
Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

Частный метод Python: улучшение инкапсуляции и безопасности
Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

Как я автоматизирую тестирование с помощью Jest
Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..

Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..