RE: [users@httpd] "Expect: 100-continue" bug in 2.2.14?

["Campbell, Scott" <Sc...@WrightExpress.com>]

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@WrightExpress.com] 
Sent: Monday, August 09, 2010 10:03 AM
To: users@httpd.apache.org
Subject: RE: [users@httpd] "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@jaqui-greenlees.net]
Sent: Saturday, August 07, 2010 12:38 AM
To: users@httpd.apache.org
Subject: Re: [users@httpd] "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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org




---------------------------------------------------------------------
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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org