httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 46709] Expect: 100-continue to an HTTP/1.0 server change Breaks .NET Web Services
Date Fri, 06 Nov 2009 13:45:26 GMT

--- Comment #2 from Sven Mueller <> 2009-11-06 05:45:21 UTC ---
Created an attachment (id=24500)
 --> (
Add support to completely ignore an "Expect: 100-continue" if env
"ignorecontinue" is set

We had a very similar issue, also with .NET clients.
As we have only relatively few clients affected by the problem (more detailed
description below), and those clients always come from the same IP, we were
able to solve the problem by the attached patch and setting the new
"ignorecontinue" environment variable for those clients.

Now to the problem itself:

In our case, the relevant URL is protected by HTTP basic auth. .Net clients
send the following header in our case:

>>>> CLIENT ----
POST /url HTTP/1.1
Content-Type: text/xml
Content-Length: 1113
Expect: 100-continue
Connection: Keep-Alive

<<<< CLIENT ----

At this point, apache httpd (2.2.3 with patches from RedHat 5.4, but I saw no
relevant changes up to the current 2.2.14) reacts like requested by the client:
It responds immediately with an error code, in this case:

>>>> SERVER  ----
HTTP/1.1 401 Authorization Required
Date: Wed, 04 Nov 2009 10:24:52 GMT
Server: Apache
WWW-Authenticate: Basic realm="Our Gateway"
Last-Modified: Thu, 17 Sep 2009 08:52:08 GMT
ETag: "23-473c221659e00"
Accept-Ranges: bytes
Content-Length: 35
Keep-Alive: timeout=15, max=10
Connection: Keep-Alive
Content-Type: text/html

This is an error page
<<<< SERVER ----

Problem here is that .Net can't handle this the way it should, the .Net client
actually keeps going by sending the body of the request, immediately followed
by the authenticated copy of the first request

>>>> CLIENT  ----
<?xml version="1.0" encoding="UTF-8"?>
POST /url HTTP/1.1
Content-Type: text/xml
Authorization: Basic <zensiert>
Content-Length: 1113
Expect: 100-continue

<?xml version="1.0" encoding="UTF-8"?>
<<<< CLIENT ----

Which httpd interprets as being a request of type:
Which is obviously not a valid request, so httpd returns code 400

For some clients, it seems to help to simply disable keepalive (setenv
nokeepalive), but for some others, this only results in no authenticated
request being sent at all.

So we tried several workarounds:
1) Use any combination of the typical MSIE workaround settings, including
   unclean ssl shutdown, downgrade-1.0, force-response-1.0. This resulted
   in varying errors, mostly having just a single request come in, for which
   code 401 was returned, then no other request following.
2) Return 417 if we knew it was a problematic customer and the Expect header
   was set. This also just resulted in no further request coming in (no matter
   wether nokeepalive was set or not).

Finally, I tried patching the httpd to allow to simply ignore the Expect header
from the known-bad clients. The resulting patch is attached. Please note that
I'm in no way an apache httpd expert, so the formating might be non-standard
and - more importantly - the logging I added might be wrong (ap_log_rerror
might be more correct than ap_log_error).

Anyway, I think the patch might be off use for others as well, and I would be
glad to see something similar in a future httpd release. 

I don't think anyone would thing copyright might apply to this simple patch,
but just in case anyone is insane enough to do so, I hereby grant all rights
related to this patch to the apache foundation. I also release the "code" under
the apache license, the GNU (L)GPL (v2 or higher) or the BSD copyright (without
the advertisement clause), at the recipients choice.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message