H2o: خطأ في H2O.next.call (env)

نظرًا لأن رسالة الخطأ اقترحت باستخدام H2O.reprocess جربت هذا الخيار الآن. نفس النتيجة: إضافة المزيد من المسار-مقاطع تعطل h2o.

hosts:
  test.local:
    listen:
      port: 80
      host: 10.0.0.10
    paths:
      "/dir0":
        file.dir: "/usr/local/www/data/testh2o/dir0"
      "/dir1":
        file.dir: "/usr/local/www/data/testh2o/dir1"
      "/wp-admin":
        mruby.handler: |
          proc {|env|
            env['SCRIPT_NAME'] = '/proxy-wp-admin'
            resp = H2O.reprocess.call(env)
            resp
          }
      "/proxy-wp-admin":
        proxy.reverse.url: "https://www.google.com"

مع فتح هذا التكوين http://test.local/wp-admin في المتصفح يعطيني صفحة Google الرئيسية.

لكن إضافة مقطع مسار آخر ، على سبيل المثال /dir2 إضافي يعطيني الخطأ التالي:

Feb  4 17:12:11 web2 h2o[34490]: received fatal signal 11
Feb  4 17:12:11 web2 h2o[34490]: [34493] 0x4cf6a0 <???> at /usr/local/bin/h2o
Feb  4 17:12:11 web2 h2o[34490]: [34493] 0x8018c5946 <pthread_sigmask+0x536> at /lib/libthr.so.3
Feb  4 17:12:11 web2 h2o[34490]: [34493] 0x8018c4eb2 <pthread_getspecific+0xe12> at /lib/libthr.so.3

هل يوجد بالفعل حد منخفض على عدد مقاطع المسار المسموح بها ؟؟؟ لابد وانها حشره. من المحتمل أن يكون نفس السعر H2O.next .

نظرًا لأن كلاهما ، H2O.next و H20.reprocess يبدو أنهما معطلان ، كان علي استكشاف حل آخر. I نفذت معالج الوكيل العكسي في mruby بعدkazuho الصورة سبيل المثال .

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

proc {|env|
    # copy headers
    headers = {}
    env.each do |key, value|
      if /^HTTP_/.match(key)
        headers[$'] = value
      end
    end
    if env['CONTENT_TYPE']
        headers['CONTENT_TYPE'] = env['CONTENT_TYPE']
    end

    # issue the request
    input = env["rack.input"] ? env["rack.input"] : ""
    if env['QUERY_STRING'].to_s != ''
        uri = env['SCRIPT_NAME'] + env['PATH_INFO'] + '?' + env['QUERY_STRING']
    else
        uri = env['SCRIPT_NAME'] + env['PATH_INFO']
    end
    req = http_request(
      "http://<backend-ip>#{uri}",
      method:  env["REQUEST_METHOD"],
      headers: headers,
      body: input,
    )

    # Extract status, headers and body, so that I can look into the headers
    status, headers, body = req.join

    # actual work done here, if a certain header is present
    [status, headers, body]
}

لا يعمل بشكل جيد حتى الآن:
H2O أو mruby يحولان العنوان الأصلي CONTENT_TYPE إلى HTTP_CONTENT_TYPE ، مما يكسر خلفية WordPress ...

مثال:
"CONTENT_TYPE"=>"application/x-www-form-urlencoded; charset=UTF-8"
يصبح
"HTTP_CONTENT_TYPE"=>"application/x-www-form-urlencoded; charset=UTF-8"

هل هناك طريقة لفرض استخدام CONTENT_TYPE ؟

وكل هذا ، فقط لأنني أردت إضافة /path في h2o.conf الخاص بي ...

utrenkner آسف https://github.com/h2o/h2o/pull/2254 بإصلاح المشكلة. مع ذلك PR H2O.next و H2O.reprocess يعمل بشكل جيد على ما أعتقد

H2O أو mruby يحولان رأس CONTENT_TYPE الأصلي إلى HTTP_CONTENT_TYPE ، والذي يكسر خلفية WordPress ...

جربت نفس معالج mruby لكن لم أتمكن من إعادة إنتاجه. أعني ، لقد أنتجت الحد الأدنى من خادم المنبع ( echo -ne "HTTP/1.1 200 OK\r\n\r\n" | nc -l 9000 ) وشاهدت الرؤوس المرسلة من h2o. تضمنت CONTENT_TYPE ، وليس HTTP_CONTENT_TYPE .
راجع للشغل إذا كنت تتبع نهج http_request هذا ، فيجب عليك تحويل الشرطات السفلية في مفاتيح تجزئة الرأس إلى واصلات: أي ، يجب عليك تحويل HTTP_X_FOO إلى X-FOO ، وليس X_FOO . أعتقد أن هذا هو سبب هذه المشكلة: تطبيق الخادم الخاص بك لا يتعرف عليه كرأس content-type ، والذي يجب معالجته بشكل خاص في معظم الحالات.

@ i110 جزيل الشكر! سأجرب التصحيح الخاص بك ، غدا.

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

@ i110 شكرا جزيلا لك! # 2254 يحل مشاكلي مع كل من H2O.next و H2O.reprocess . لقد أضفت المزيد من مقاطع /path إلى h2o.conf ، فقط للتحقق من أنها تعمل بالفعل . ونعم ، هو كذلك!