Faraday: Mencoba mencatat badan permintaan, itu mencatat respons sebagai gantinya

Dibuat pada 14 Jul 2016  ·  14Komentar  ·  Sumber: lostisland/faraday

Hai.

Saya mencoba membuat 0.9.2 mencetak badan permintaan & tanggapan.
Ini tidak didokumentasikan, tetapi dibahas dalam PR #277.
Saya pikir, saya telah membuat pengaturan yang tepat. Saya menggunakan Faraday melalui Saorin..

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

Di mata saya, output debug tidak mencetak request body , tetapi mencetak response body (tidak diharapkan).
(dan mengikuti badan respons pencetakan lagi, seperti yang diharapkan).

Jadi saya mendapatkan sth seperti itu di log: (perhatikan nilai untuk request . Ini sebenarnya duplikat dari 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"}

Periksa kode ini dari 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

Jika saya membacanya dengan benar, baris: debug('request') { dump_body(env[:body]... mencetak bukan var.

Dan, sebenarnya memeriksa env[] , saya tidak dapat menemukan badan permintaan di mana pun :-( Hanya request_headers , request_options dan response data.

Karena, saya tidak percaya tidak ada yang memperhatikan itu sebelumnya, mungkin saya telah membuat beberapa kesalahan. Tetapi dimana?

unconfirmed

Komentar yang paling membantu

Hai @iMacTia , saya juga terjebak dengan masalah ini. Saya telah menemukan bahwa masalah direproduksi ketika Anda mendefinisikan adaptor sebelum logger.

Badan permintaan log kode ini:

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

Ini tidak:

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

Semua 14 komentar

@nthx saya juga melihat ini..

@stve - apakah laporan itu masuk akal bagi Anda?

mungkin perlu konfigurasi permintaan juga? Padahal belum coba..

<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

Ini adalah kondisi balapan standar, saya pikir. Apa yang terjadi di sini adalah env[:body] pernah disetel ke badan permintaan. Tetapi pada saat metode log atau dump_body dijalankan, badan respons telah menggantikan badan permintaan di dalam env[:body] dan tidak ada variabel/salinan lebih lanjut yang dibuat dari badan permintaan asli, bukan berarti itu akan memperbaiki keadaan. env bersifat global untuk permintaan, kita tidak boleh menganggap middleware dijalankan secara sinkron dan berurutan sebelum panggilan dilakukan.

Perbaikan yang mudah adalah dengan menggunakan dua nilai env untuk melacak isi, satu untuk permintaan, dan satu untuk tanggapan.

Kami tidak memiliki bug dengan header ini karena ada dua nilai terpisah di sana: request_headers dan response_headers . Jadi mengapa tidak mengikuti jejak mereka ...

Atau, buat nilai env kedua yang disebut request_body dan simpan badan permintaan dua kali di env.request_body dan env.body . Dengan begitu kode apa pun yang bergantung pada perilaku yang ada akan menyimpannya, tetapi kode yang diperbarui seperti fungsi logging kami di sini dapat menggunakan request_body jika ada.

Jika ini tidak segera diperbaiki di bagian hulu, kemungkinan besar saya akan menambal Faraday dan menggunakan garpu saya sendiri. Saya tidak dapat memiliki logging yang tidak dapat diandalkan ...

@nthx , maaf jika saya melewatkannya, tetapi logger mana yang Anda gunakan?
Kode terlihat baik-baik saja, satu-satunya "masalah" yang dapat saya lihat adalah dengan procs yang digunakan untuk mengevaluasi pesan. Ini biasanya tidak menjadi masalah, kecuali evaluasi mereka terjadi SETELAH permintaan diproses.
Saya tidak yakin ini mungkin dengan logger standar (sinkron), jadi saya ingin tahu yang mana yang Anda gunakan :)

Sebenarnya, saya telah menggunakan logger saya sendiri dalam hal ini. Ini berhasil untuk pesan lain, jadi saya pikir itu tidak akan menyebabkan masalah.
Saya akan memverifikasi dengan logger standar dan memeriksa ulang milik saya, dan memberi tahu Anda.

Hai @nthx , semoga berhasil dengan tes Anda? Apakah Anda menemukan sesuatu yang baru?
Saya ingin menutup masalah ini dan memahami jika masalahnya terletak pada Faraday atau logger

Saya akan menutup ini dengan asumsi kesalahan terletak pada logger saat saya menguji yang standar dan berfungsi dengan baik untuk saya.

@nthx jangan ragu untuk membuka kembali jika Anda memiliki bukti baru yang menunjuk ke Faraday sebagai kemungkinan penyebabnya

Saya masih memiliki bug ini, menggunakan Logger bawaan Faraday pada saat itu, tetapi saya menyelesaikannya dengan menulis logger saya sendiri di middleware, dan kemudian dengan beralih dari menggunakan Faraday ke sesuatu yang lebih sederhana.

Hai @iMacTia , saya juga terjebak dengan masalah ini. Saya telah menemukan bahwa masalah direproduksi ketika Anda mendefinisikan adaptor sebelum logger.

Badan permintaan log kode ini:

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

Ini tidak:

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

Hai @llxff ,

ya itu diharapkan karena urutan middlewares sangat penting dan adaptor harus selalu berada di bawah.
Jika Anda meletakkan adaptor SEBELUM, maka permintaan akan dilakukan sebelum adaptor logger tercapai, menyebabkan respons dicatat dua kali.
Juga, saya sekarang membaca kembali masalah @nthx dengan ini dan saya baru menyadari dia kehilangan adaptor di tumpukan middlewares-nya:

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

Saya juga telah memeriksa kode di permata Saorin dan tampaknya sepenuhnya salah untuk alasan yang sama persis: https://github.com/mashiro/saorin/blob/master/lib/saorin/client/faraday. rb#L16

Masuk akal. Saya belum dapat memverifikasinya lagi, tetapi ada pemikiran lain... Saya telah membaca laporan awal saya dan dikatakan:

Ini tidak didokumentasikan, tetapi dibahas dalam PR #277.

Apakah ini masih terjadi, bahwa tidak ada dokumentasi tentang bagaimana sebenarnya mengonfigurasi logging tanggapan?
Jika dokumen ada di sana, maka tidak akan ada keraguan tentang bagaimana melakukannya.

Bisakah Anda membuat tiket untuk memperbarui dokumen? Atau buka lagi yang ini mungkin?

Juga - siapa yang harus menghubungi Saorin guys?

Hai @nthx Anda benar sekali, dokumentasi kami saat ini tidak cukup detail (sebenarnya, kami menggunakan Readme sebagai "dokumentasi").
Dalam kasus spesifik Anda, ada contoh ke-3 di bagian https://github.com/lostisland/faraday/blob/master/README.md#basic -use yang menunjukkan cara menggunakan middleware logger, tapi saya setuju itu tidak cukup .
Kami berencana untuk mengubah Wiki dalam waktu dekat yang akan membantu mengurangi masalah semacam ini.

Sesuai Saorin, saya sarankan Anda membuka masalah di halaman mereka dengan memberikan contoh dengan kode yang gagal dan melaporkan komentar saya, yang akan membantu mereka melacak masalah tersebut.
Saya lebih suka Anda melakukan ini karena Anda secara aktif menggunakan permata mereka dan meskipun akan dapat memberikan informasi tambahan yang mereka butuhkan.

Terima kasih

Hai,

Saya baru saja melihat masalah ini dan saya mengerti mengapa permintaan saya tidak ditandatangani dengan baik.

Kami membuat middleware yang menambahkan tanda tangan sebelum membuat permintaan.
Saat kami mendefinisikan adaptor sebelum menggunakan middleware, permintaan dikirim sebelum menambahkan header otorisasi.

Efek sampingnya adalah middleware menggunakan env.body untuk membuat tanda tangan dan karenanya menggunakan badan respons untuk membuat tanda tangan.

Saat saya mendefinisikan adaptor di bagian atas koneksi, log saya juga salah dan saya berpikir bahwa skrip tanda tangan saya juga salah.

Salam Hormat!

Apakah halaman ini membantu?
0 / 5 - 0 peringkat