Faraday: في محاولة لتسجيل نص الطلب ، يقوم بتسجيل الاستجابة بدلاً من ذلك

تم إنشاؤها على ١٤ يوليو ٢٠١٦ · 14تعليقات · مصدر: lostisland/faraday

أهلا.

أحاول جعل 0.9.2 طباعة كل من هيئات الطلب والاستجابة.
لم يتم توثيق هذا ، ولكن تمت مناقشته في # 277 PR.
أعتقد ، لقد أجريت الإعداد المناسب. أنا أستخدم فاراداي عبر Saorin ..

  <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 في ١٦ فبراير ٢٠١٧

👍6

ال 14 كومينتر

nthx أرى هذا أيضًا ..

stevenjack في ١٨ يوليو ٢٠١٦

stve - هل التقرير منطقي بالنسبة لك؟

nthx في ٢٨ يوليو ٢٠١٦

ربما يحتاج طلب التكوين أيضا؟ لم أحاول ذلك رغم ذلك ..

<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 في ٢٨ يوليو ٢٠١٦

إنها حالة سباق معيارية ، على ما أعتقد. ما يحدث هنا هو أنه تم تعيين env[:body] مرة واحدة على نص الطلب. ولكن بحلول الوقت الذي يتم فيه تنفيذ أسلوب السجل أو dump_body ، استبدل نص الاستجابة نص الطلب داخل env[:body] ولم يتم عمل أي متغيرات / نسخ أخرى من نص الطلب الأصلي ، ولا يعني ذلك بالضرورة أنه سيصلح الأشياء. env عالمي بالنسبة للطلب ، لا يجب أن نفترض أن البرامج الوسيطة تعمل بشكل متزامن وبالترتيب قبل إجراء المكالمة.

قد يكون الحل السهل هو استخدام قيمتين env لتتبع الهيئات ، واحدة للطلب ، وواحدة للرد.

ليس لدينا هذا الخطأ مع الرؤوس نظرًا لوجود قيمتين منفصلتين هناك: request_headers و response_headers . فلماذا لا تحذو حذوهم ...

بدلاً من ذلك ، قم بعمل قيمة ثانية env تسمى request_body وقم بتخزين نص الطلب مرتين في كل من env.request_body و env.body . وبهذه الطريقة ، فإن أي كود يعتمد على السلوك الحالي يحتفظ به ، لكن الكود المحدث مثل وظيفة التسجيل هنا يمكن أن يستخدم request_body إذا كان موجودًا.

إذا لم يتم إصلاح هذا الأمر قريبًا ، فمن المحتمل جدًا أن أقوم بتصحيح Faraday واستخدام شوكة خاصة بي. لا يمكنني الحصول على تسجيل غير موثوق به ...

LouisStAmour في ١٠ أغسطس ٢٠١٦

nthx ، آسف إذا فاتني ذلك ، ولكن ما هو المسجل الذي تستخدمه؟
يبدو الرمز جيدًا ، المشكلة الوحيدة التي يمكنني رؤيتها هي مع procs المستخدمة لتقييم الرسالة. هذه ليست مشكلة في العادة ، ما لم يتم تقييمهم بعد معالجة الطلب.
لست متأكدًا من أن هذا ممكن مع المسجل القياسي (المتزامن) ، لذلك أود أن أعرف أي واحد تستخدمه :)

iMacTia في ٢٣ أغسطس ٢٠١٦

في الواقع ، كنت أستخدم أداة التسجيل الخاصة بي في هذه الحالة. لقد نجحت مع رسائل أخرى ، لذلك لم أعتقد أنها قد تسبب مشكلة.
سوف أتحقق من المسجل القياسي وأعيد التحقق من بلدي ، وأعلمك بذلك.

nthx في ٢٩ أغسطس ٢٠١٦

مرحبًا nthx ، هل من حظك في اختباراتك؟ هل اكتشفت شيئًا جديدًا؟
أود أن أغلق هذه المسألة وأفهم ما إذا كانت المشكلة تكمن في فاراداي أم المسجل

iMacTia في ١٣ أكتوبر ٢٠١٦

سأغلق هذا على افتراض أن الخطأ يقع على المسجل حيث اختبرت المعيار القياسي ويعمل بشكل جيد بالنسبة لي.

nthx لا تتردد في إعادة الفتح في حال كان لديك أي دليل جديد يشير إلى فاراداي باعتباره السبب المحتمل

iMacTia في ٤ نوفمبر ٢٠١٦

لا يزال لدي هذا الخطأ ، باستخدام Faraday المدمج في Logger في ذلك الوقت ، لكنني قمت بحلها عن طريق كتابة المسجل الخاص بي في برمجية وسيطة ، وبعد ذلك بالتبديل من استخدام Faraday إلى شيء أبسط.

LouisStAmour في ٤ نوفمبر ٢٠١٦

مرحبًا 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 في ١٦ فبراير ٢٠١٧

👍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 gem ويبدو خاطئًا تمامًا لنفس السبب بالضبط: https://github.com/mashiro/saorin/blob/master/lib/saorin/client/faraday. rb # L16

iMacTia في ١٦ فبراير ٢٠١٧

👍5

من المنطقي. لا يمكنني التحقق من ذلك مرة أخرى ، ولكن لدي فكرة أخرى ... لقد قرأت تقريري الأولي وهو يقول:

لم يتم توثيق هذا ، ولكن تمت مناقشته في # 277 PR.

هل لا يزال هذا هو الحال ، حيث لا توجد وثائق حول كيفية تكوين تسجيل الاستجابات بالفعل؟
إذا كانت المستندات موجودة ، فلن يكون هناك شك في كيفية القيام بذلك.

هل يمكنك إنشاء تذكرة لتحديث المستندات؟ أو إعادة فتح هذا ربما؟

أيضا - من يجب أن يتصل بشباب Saorin؟

nthx في ٢٠ فبراير ٢٠١٧

مرحبًا nthx ، أنت محق تمامًا في أن وثائقنا حاليًا ليست مفصلة بشكل كافٍ (في الواقع ، نحن نستخدم الملف التمهيدي كـ "وثائق").
في حالتك المحددة ، يوجد المثال الثالث في https://github.com/lostisland/faraday/blob/master/README.md#basic -use القسم الذي يوضح كيفية استخدام البرنامج الوسيط المسجل ، لكنني أوافق على أن هذا ليس كافيًا .
نحن نخطط للحصول على ويكي مجدد في المستقبل القريب والذي من شأنه أن يساعد في التخفيف من هذا النوع من المشكلات.

وفقًا لـ Saorin ، أقترح عليك فتح مشكلة على صفحتهم مع تقديم أمثلة مع الكود الفاشل والإبلاغ عن تعليقي ، مما يساعدهم على تعقب المشكلة.
أنا أفضل أن تفعل هذا لأنك تستخدم جوهرة خاصة بهم بنشاط وعلى الرغم من أنها ستكون قادرة على تقديم أي معلومات إضافية قد يحتاجون إليها.

شكرا

iMacTia في ٢٠ فبراير ٢٠١٧

أهلا،

لقد رأيت للتو هذه المشكلة وأدرك سبب عدم توقيع طلبي بشكل جيد.

أنشأنا برمجية وسيطة تضيف توقيعًا قبل تقديم الطلب.
نظرًا لتعريف المحول قبل استخدام البرنامج الوسيط ، تم إرسال الطلب قبل إضافة رأس التفويض.

كان التأثير الجانبي هو أن البرمجيات الوسيطة كانت تستخدم env.body لبناء التوقيع ولذا كانت تستخدم هيئة الاستجابة لبناء التوقيع.

نظرًا لأنني كنت أقوم بتعريف المحول في الجزء العلوي من الاتصال ، كانت سجلاتي خاطئة أيضًا وكنت أفكر في أن نص التوقيع الخاص بي كان خاطئًا أيضًا.

مع أطيب التحيات!