Faraday: Пытаясь зарегистрировать тело запроса, вместо этого регистрируется ответ

Созданный на 14 июл. 2016 · 14Комментарии · Источник: lostisland/faraday

Привет.

Я пытаюсь заставить 0.9.2 печатать как тело запроса, так и тело ответа.
Это не задокументировано, но обсуждается в #277 PR.
Я думаю, я сделал правильную настройку. Я использую Фарадей через Саорин..

  <strong i="9">@client</strong> = Saorin::Client.new(:url => @endpoint) do |connection|
    connection.response :logger, <strong i="10">@logger</strong>, :bodies => true
  end

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

Итак, я получаю что-то вроде этого в журнале: (обратите внимание на значение для request . На самом деле это дубликат response .

post https://foo.bar.com/api/3.0/json-rpc
request User-Agent: "Faraday v0.9.2"
Content-Type: "application/json"
request {"result":{"accessGranted":false},"id":"foo","jsonrpc":"2.0"}
Status 200
response server: "nginx"
date: "Thu, 14 Jul 2016 21:28:21 GMT"
content-type: "application/json"
transfer-encoding: "chunked"
connection: "close"
response {"result":{"accessGranted":false},"id":"foo","jsonrpc":"2.0"}

Проверьте этот код faraday/response/logger.rb :

    def call(env)
      info "#{env.method} #{env.url.to_s}"
      debug('request') { dump_headers env.request_headers }
      debug('request') { dump_body(env[:body]) } if env[:body] && log_body?(:request)
      super
    end

    def on_complete(env)
      info('Status') { env.status.to_s }
      debug('response') { dump_headers env.response_headers }
      debug('response') { dump_body env[:body] } if env[:body] && log_body?(:response)
    end

Если я правильно понял, строка: debug('request') { dump_body(env[:body]... выводит не тот var.

И, фактически проверяя env[] , я нигде не могу найти тело запроса :-( Только данные request_headers , request_options и response .

Поскольку, я не думаю, что кто-то заметил это раньше, возможно, я сделал какую-то ошибку. Но где?

unconfirmed

Источник

nthx

Самый полезный комментарий

Привет @iMacTia , я тоже столкнулся с этой проблемой. Я обнаружил, что эта проблема воспроизводится, когда вы определяете адаптер перед регистратором.

Это тело запроса журнала кода:

Faraday.new(url: url) do |faraday|
  faraday.response :logger, ::Logger.new(STDOUT), bodies: true
  faraday.adapter Faraday.default_adapter
end

Это не:

Faraday.new(url: url) do |faraday|
  faraday.adapter Faraday.default_adapter
  faraday.response :logger, ::Logger.new(STDOUT), bodies: true
end

llxff 16 февр. 2017

👍6

Все 14 Комментарий

@nthx Я тоже это вижу ..

stevenjack 18 июл. 2016

@stve - отчет имеет смысл для вас?

nthx 28 июл. 2016

может быть, ему тоже нужна конфигурация запроса? Хотя не пробовал..

<strong i="6">@client</strong> = Saorin::Client.new(:url => @endpoint) do |connection|
  connection.response :logger, <strong i="7">@logger</strong>, :bodies => true
  connection.request :logger, <strong i="8">@logger</strong>, :bodies => true
end

nthx 28 июл. 2016

Думаю, это стандартное состояние гонки. Здесь происходит то, что env[:body] когда-то было установлено в тело запроса. Но к тому времени, когда выполняется метод журнала или dump_body, тело ответа заменяет тело запроса внутри env[:body] , и никакие другие переменные/копии исходного тела запроса не создаются, хотя это не обязательно исправит ситуацию. env является глобальным для запроса, мы не должны предполагать, что промежуточное ПО выполняется синхронно и по порядку до выполнения вызова.

Простое решение — использовать два значения env для отслеживания тел, одно для запроса и одно для ответа.

У нас нет этой ошибки с заголовками, потому что там два отдельных значения: request_headers и response_headers . Так почему бы не последовать их примеру...

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

Если в ближайшее время это не будет исправлено, я, скорее всего, исправляю Фарадея и использую свой собственный форк. У меня не может быть ненадежного ведения журнала...

LouisStAmour 10 авг. 2016

@nthx , извините, если пропустил, но какой регистратор вы используете?
Код выглядит нормально, единственная «проблема», которую я вижу, связана с процедурами, используемыми для оценки сообщения. Обычно это не проблема, если только их оценка не происходит ПОСЛЕ обработки запроса.
Я не уверен, что это возможно со стандартным (синхронным) регистратором, поэтому я хотел бы знать, какой из них вы используете :)

iMacTia 23 авг. 2016

На самом деле, я использовал свой собственный регистратор в этом случае. Это работало для других сообщений, поэтому я не думал, что это может вызвать проблему.
Я проверю с помощью стандартного регистратора и перепроверю свой собственный, и дам вам знать.

nthx 29 авг. 2016

Привет @nthx , тебе повезло с тестами? Вы открыли для себя что-то новое?
Я хотел бы закрыть этот вопрос и понять, проблема заключается в Фараде или регистраторе

iMacTia 13 окт. 2016

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

@nthx не стесняйтесь открывать заново, если у вас есть какие-либо новые доказательства, указывающие на Фарадея как на возможную причину.

iMacTia 4 нояб. 2016

У меня все еще была эта ошибка, когда я использовал встроенный Logger Faraday, но я решил ее, написав свой собственный регистратор в промежуточном программном обеспечении, а позже переключившись с использования Faraday на что-то более простое.

LouisStAmour 4 нояб. 2016

Это тело запроса журнала кода:

Faraday.new(url: url) do |faraday|
  faraday.response :logger, ::Logger.new(STDOUT), bodies: true
  faraday.adapter Faraday.default_adapter
end

Это не:

Faraday.new(url: url) do |faraday|
  faraday.adapter Faraday.default_adapter
  faraday.response :logger, ::Logger.new(STDOUT), bodies: true
end

llxff 16 февр. 2017

👍6

Привет @llxff ,

да, это ожидаемо, поскольку порядок промежуточного программного обеспечения имеет решающее значение, а адаптер всегда должен быть внизу.
Если вы поместите адаптер ДО, то запрос будет выполнен до того, как будет достигнут адаптер регистратора, в результате чего ответ будет зарегистрирован дважды.
Кроме того, я сейчас перечитываю проблему @nthx с этим, и я только что понял, что ему не хватает адаптера в его стеке промежуточного программного обеспечения:

<strong i="11">@client</strong> = Saorin::Client.new(:url => @endpoint) do |connection|
    connection.response :logger, <strong i="12">@logger</strong>, :bodies => true
  end

Я также проверил код в драгоценном камне Saorin , и он выглядит совершенно неправильно по той же самой причине: https://github.com/mashiro/saorin/blob/master/lib/saorin/client/faraday. рб#L16

iMacTia 16 февр. 2017

👍5

Имеет смысл. Я еще не могу проверить это еще раз, но есть еще одна мысль... Я прочитал свой первоначальный отчет, и в нем говорится:

Это не задокументировано, но обсуждается в #277 PR.

Это все еще так, что нет документации о том, как на самом деле настроить ведение журнала ответов?
Если бы были документы, то сомнений в том, как это сделать, не было бы.

Не могли бы вы создать тикет для обновления документов? Или, может быть, снова открыть этот?

Кроме того, кому следует связаться с ребятами из Саорина?

nthx 20 февр. 2017

Привет @nthx , вы совершенно правы, наша документация в настоящее время недостаточно детализирована (на самом деле мы используем Readme как «документацию»).
В вашем конкретном случае есть 3-й пример в разделе https://github.com/lostisland/faraday/blob/master/README.md#basic -use, который показывает, как использовать промежуточное программное обеспечение регистратора, но я согласен, что этого недостаточно. .
В ближайшем будущем мы планируем обновить Wiki, что должно помочь решить подобные проблемы.

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

Спасибо

iMacTia 20 февр. 2017

Привет,

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

Мы создали промежуточное ПО, которое добавляет подпись перед выполнением запроса.
Поскольку мы определяем адаптер перед использованием промежуточного программного обеспечения, запрос был отправлен до добавления заголовка авторизации.

Побочным эффектом было то, что промежуточное ПО использовало env.body для создания подписи, и поэтому оно использовало тело ответа для создания подписи.

Поскольку я определял адаптер в верхней части соединения, мои журналы также были неправильными, и я думал, что мой сценарий подписи также был неправильным.

С наилучшими пожеланиями!