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 로 바꾸어 WordPress 백엔드를 중단합니다...

예시:
"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으로 변환하여 WordPress 백엔드를 중단합니다...

동일한 mruby 처리기를 시도했지만 재현할 수 없습니다. 내 말은, 최소한의 업스트림 서버( echo -ne "HTTP/1.1 200 OK\r\n\r\n" | nc -l 9000 )를 생성하고 h2o에서 보낸 헤더를 확인합니다. 여기에는 CONTENT_TYPE 이 아니라 HTTP_CONTENT_TYPE .
이 HTTP_REQUEST 접근을 BTW, 당신은 하이픈 헤더 해시 키의 변환 밑줄에 있습니다입니다, 당신은 변환해야 HTTP_X_FOO 에 X-FOO 하지 X_FOO . 이것이 그 문제의 원인이라고 생각합니다. 서버 구현은 대부분의 경우 특별히 처리해야 하는 content-type 헤더로 인식하지 못합니다.

@i110 정말 감사합니다! 내일 패치를 시험해 보겠습니다.

그리고 위의 mruby 핸들러를 테스트해주셔서 감사합니다. 사실, 밑줄을 하이픈으로 바꾸는 것을 완전히 잊어 버렸습니다. 이 변경으로 인해 의도한 대로 작동하고 CONTENT_TYPE 는 CONTENT_TYPE !

@i110 정말 감사합니다! #2254 는 H2O.next 및 H2O.reprocess 문제를 모두 해결합니다. 실제로 작동하는지 확인하기 위해 h2o.conf에 /path 세그먼트를 더 추가했습니다. 예, 그렇습니다!