Uploaded image for project: 'JBoss Core Services'
  1. JBoss Core Services
  2. JBCS-451

mod_proxy_http incorrectly requires continue response after already sending response data


    • 24
    • +
    • Workaround Exists
      • Use mod_proxy_ajp instead
      • Or SetEnv force-proxy-request-1.0 1
    • Hide
      • On httpd, proxy to EAP 7:
        ProxyPass / http://localhost:8080/ ping=10
      • Deploy attached war on EAP 7
      • Issue request to httpd:
        curl -vvvk -d "name=TTOTOTOT" localhost/post-timeout/
      On httpd, proxy to EAP 7: ProxyPass / http: //localhost:8080/ ping=10 Deploy attached war on EAP 7 Issue request to httpd: curl -vvvk -d "name=TTOTOTOT" localhost/post-timeout/

      mod_proxy_http always requires a continue response from the back end for a proxied POST. This is incorrect when it has already sent response data. The RFC7231 related to HTTP1.1 section 5.1.1 states:

      A server MAY omit sending a 100 (Continue) response if it has
            already received some or all of the message body for the
            corresponding request, or if the framing indicates that there is
            no message body

      So then mod_proxy_http sends the Expect header along with the request body and then waits for the 100-continue, which could be an issue if the backend chooses to omit it per the spec above. That can lead to POST requests hitting the ping timeout undesirably.

      This was never a concern with EAP 6/JBossWeb since it always sent the 100-continue regardless. But currently, EAP 7/Undertow chooses to omit it in this scenario, which causes request failures and error states from ping timeouts. This also impacts mod_cluster if proxying over http.

      If mod_proxy_http is always going to require a 100-continue response, then we have to ensure it doesn't send the request body before that response. Or it may be helpful to provide some other means of disabling this POST 100-continue ping besides force-proxy-request-1.0.

            rhn-engineering-mturk Mladen Turk
            rhn-support-aogburn Aaron Ogburn
            Michal Karm Michal Karm
            1 Vote for this issue
            13 Start watching this issue