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 टूटे हुए प्रतीत होते हैं, मुझे एक और समाधान तलाशना पड़ा। मैंने @kazuho के उदाहरण के बाद, mruby में एक रिवर्स प्रॉक्सी हैंडलर लागू किया।

मेरे परीक्षण सर्वर पर यह काम करता है। मैं इसे जल्द ही उत्पादन में तैनात करूंगा। हो सकता है कि यह किसी और को उपर्युक्त विधियों के साथ समान समस्याओं में चलने में मदद करे:

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 , जो एक वर्डप्रेस बैकएंड को तोड़ देता है...

उदाहरण:
"CONTENT_TYPE"=>"application/x-www-form-urlencoded; charset=UTF-8"
हो जाता है
"HTTP_CONTENT_TYPE"=>"application/x-www-form-urlencoded; charset=UTF-8"

क्या इसे केवल CONTENT_TYPE का उपयोग करने के लिए मजबूर करने का कोई तरीका है?

और यह सब, सिर्फ इसलिए कि मैं अपने h2o.conf में एक और /path जोड़ना चाहता था...

@utrenkner देर से आने के लिए क्षमा करें। मुझे उम्मीद है कि https://github.com/h2o/h2o/pull/2254 समस्या को ठीक कर देगा। उस पीआर के साथ H2O.next और H2O.reprocess काम करता है मुझे लगता है

H2O या mruby मूल CONTENT_TYPE हेडर को HTTP_CONTENT_TYPE में बदल देता है, जो वर्डप्रेस बैकएंड को तोड़ देता है...

मैंने एक ही मृबी हैंडलर की कोशिश की लेकिन इसे पुन: पेश नहीं कर सका। मेरा मतलब है, मैंने न्यूनतम अपस्ट्रीम सर्वर ( echo -ne "HTTP/1.1 200 OK\r\n\r\n" | nc -l 9000 ) को जन्म दिया और h2o से भेजे गए हेडर देखें। इसमें CONTENT_TYPE , न कि HTTP_CONTENT_TYPE ।
BTW यदि आप इस http_request दृष्टिकोण को लेते हैं, तो आपको हेडर हैश कुंजियों में अंडरस्कोर को हाइफ़न में बदलना होगा: यानी, आपको HTTP_X_FOO से X-FOO कनवर्ट करना होगा, न कि X_FOO । मुझे लगता है कि यह उस समस्या का कारण है: आपका सर्वर कार्यान्वयन इसे content-type शीर्षलेख के रूप में नहीं पहचानता है, जिसका ज्यादातर मामलों में विशेष रूप से इलाज किया जाना है।

@ i110 बहुत बहुत धन्यवाद! मैं कल आपका पैच आज़माउंगा।

और उपरोक्त मृबी हैंडलर का परीक्षण करने के लिए भी धन्यवाद। दरअसल, मैं अंडरस्कोर को हाइफ़न में बदलने के बारे में पूरी तरह से भूल गया था। उस परिवर्तन के साथ, यह इरादा के अनुसार काम करता है और CONTENT_TYPE रहता है CONTENT_TYPE !

@i110 बहुत-बहुत धन्यवाद! #2254 H2O.next और H2O.reprocess दोनों के साथ मेरी समस्याओं का समाधान करता है। मैंने h2o.conf में और भी अधिक /path सेगमेंट जोड़े, बस यह जांचने के लिए कि यह वास्तव में काम करता है। और, हाँ, यह करता है!