Apache and mod_proxy not handling HTTP 100-continue from client HTTP 417

user_298388 0
Viewed 23080

'm building some webby magic and am using Apache to front our tomcat server, forwarding requests to tomcat on port 8080. I have an issue using Apache and mod_proxy to forward requests. It appears the client (a web application) sends an HTTP 100-continue to which Apache responds with a 417 Expectation Failed.

When I take Apache out of the picture and send requests directly to tomcat on port 8080, the request is successful and the client is sent a 200 OK.

My Apache config looks like:

ServerName abcproxy DocumentRoot /apps/apache-content/default

AddOutputFilterByType DEFLATE text/html text/plain text/css application/javascript text/xml

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

ExpiresActive on
ExpiresDefault "access 0 seconds"

ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/

        ProxyPreserveHost On

CustomLog /apps/ocp-logs/apache/abcproxy.log combined

Anyone see where i'm going wrong?

proxy apache
3 Answers

In our realy particular case, it was the proxy answering with 417. Then again, the deploy seemed to have ignored the nonProxyHosts settings. Effectively, we had run into this bug: https://github.com/mojohaus/jaxb2-maven-plugin/issues/60 thus jaxb2-maven-plugin mangled our proxy settings, and the proxy answered 417.

mvn clean deploy

failed. While

mvn deploy

worked. Best workaround I found (see issue linked above) was to use a different wagon which does not get broken by jaxb2-maven-plugin (version 2.4 still known to have this proxy bug):

<extensions>
    <extension>
        <groupId>org.apache.maven.wagon</groupId>
        <artifactId>wagon-http-lightweight</artifactId>
        <version>3.3.2</version>
    </extension>
</extensions>
user_17471400

I hit this 417 Expectation Failed error while configuring Ivanti cloud services (ITSM) with API integrations with Tufin SecureChange (firewall rule automation) running apache on the frontend. This patch solved my issues.

user_122355710
Related