So we have gotten further, and I thought I would share the results. We are doing all tests with the latest 2.2.16 code. Per the discussion at https://issues.apache.org/bugzilla/show_bug.cgi?id=46709, we decided to comment out the "if (r->expecting_100) {return HTTP_EXPECTATION_FAILED;" line of code in mod_proxy_http.c. Doing this allowed our XML/SOAP request to continue to our backend IIS server. ------------------------------------------- /* * Send the HTTP/1.1 request to the remote server */ if (apr_table_get(r->subprocess_env, "force-proxy-request-1.0")) { buf = apr_pstrcat(p, r->method, " ", url, " HTTP/1.0" CRLF, NULL); force10 = 1; /* * According to RFC 2616 8.2.3 we are not allowed to forward an * Expect: 100-continue to an HTTP/1.0 server. Instead we MUST return * a HTTP_EXPECTATION_FAILED * Disabled for .NET clients if (r->expecting_100) { return HTTP_EXPECTATION_FAILED; } */ p_conn->close++; } else { buf = apr_pstrcat(p, r->method, " ", url, " HTTP/1.1" CRLF, NULL); force10 = 0; ------------------------------------------- Doing this however should not have worked. This above section of code is only supposed to be called IF the force-proxy-request-1.0 variable is set. We do not have this set in our configs. Upon further digging, we see that our HTTP/1.1 request is coming in, but is getting proxied to the back-end as an HTTP/1.0 request. INCOMING (Eth0) -------- POST /sitetransactions/MySOAService.asmx HTTP/1.1 Content-Type: text/xml; charset=utf-8 SOAPAction: "http://tempuri.org/getIdentity" Host: X Content-Length: 235 Expect: 100-continue Connection: Keep-Alive OUTGOING via mod_proxy (Eth1) ---------------------- POST /sitetransactions/MySOAService.asmx HTTP/1.0 Host: X Content-Type: text/xml; charset=utf-8 SOAPAction: "http://tempuri.org/getIdentity" Expect: 100-continue X-Forwarded-For: 192.168.1.2 X-Forwarded-Host: X X-Forwarded-Server: X Content-Length: 235 We are using two network interfaces (eth0/eth1). Eth0 receives the front-end HTTP/1.1 request. Apache sends the proxied back-end request out through Eth1. Finally, if we use only one network interface, all incoming HTTP/1.1 traffic gets proxied out through the same network interface as HTTP/1.1 traffic. Our conclusion is that when mod_proxy is handing off the proxy request to a different network interface, the HTTP protocol is somehow getting converted to a 1.0 from a 1.1, which makes no sense to me. This is as far as we have dug. We aren't 100% comfortable using the "patched"/commented out code in mod_proxy_http.c, but so far, it's the only way we can get our code working. Scott -----Original Message----- From: Campbell, Scott [mailto:Scott_Campbell@xxxxxxxxxxxxxxxxx] Sent: Monday, August 09, 2010 10:03 AM To: users@xxxxxxxxxxxxxxxx Subject: RE: "Expect: 100-continue" bug in 2.2.14? Per Eric, I added the %{Expect}i log entry. LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"SCOTT\" \"%{User-Agent}i\"\"%{Expect}i\"" scott CustomLog "|/usr/local/apache2/bin/rotatelogs /usr/local/apache2/logs/scott.log 86400" scott X.X.X.X - - [09/Aug/2010:09:43:34 -0400] "POST /sitetransactions/XXXTransactionsService.asmx HTTP/1.1" 417 440 "-" "SCOTT" "-""100-continue" >From looking at it, the "Expect" value coming in from the client does seem to be correct. It's also attached per your request. I also tried setting "AddDefaultCharset UTF-8" and "AddCharset UTF-8 .xml", but they did not seem to make a difference. Scott -----Original Message----- From: J. Greenlees [mailto:lists@xxxxxxxxxxxxxxxxxxx] Sent: Saturday, August 07, 2010 12:38 AM To: users@xxxxxxxxxxxxxxxx Subject: Re: "Expect: 100-continue" bug in 2.2.14? Eric Covener wrote: >> Expect: 100-continue > > Can you log %{Expect}i from apache and include the output in an > attachment? Wondering if there's some subtle thing in the string being > missed, or a failure to trim whitespace, etc. > something like their app working with utf-8 and the apache proxy working with iso-8859-1 could also give an odd response. The two charsets should be compatible, but it may not be the case. The conversion may be reading the zeros as the letter o in the 100. [ or similar. ] or it could be the app using the letter o because of a typo. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx