httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 47810] New: mod_proxy_http violates RFC and common sense
Date Wed, 09 Sep 2009 13:06:30 GMT

           Summary: mod_proxy_http violates RFC and common sense
           Product: Apache httpd-2
           Version: 2.2.11
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_proxy

--- Comment #0 from Chuck Short <> 2009-09-09 06:06:26 PDT ---

This was recently reported in launchpad:

Binary package hint: apache2

If I send a request containing the header "Expect: 100-continue" to a location
that is directed to a backend HTTP server using mod_proxy_http, then the
following happens:

The client sends the request:

   PUT /some/path/somewhere HTTP/1.1
   Expect: 100-continue

Then apache will respond with 100 Continue even though it hasn't even contacted
the backend server yet.

   100 Continue

Fine, the client will start sending the body now, because apache asked it to.
Meanwhile, apache will start contacting the backend server, using the Expect

   PUT /some/path HTTP/1.1
   Expect: 100-continue
   X-Forwarded-For: and so on

Okay, the server now assumes there will be no body yet because of the
Expect-header, and starts processing the request.

Then, unexpectedly, apache will continue sending the body, even though the
server hasn't done anything yet. Now, if the server doesn't respond with "100
Continue", but, for example, with "401 Unauthorized", then the body will be
interpreted as the next request. Apache however ignores any response from the
server until it's done sending the body, at which point the server has been
sending "400 Bad request" messages so fast that now both sides of the
conversation are thoroughly confused and apache doesn't even bother to send a
meaningful response to the client; all connections are eventually closed.

Arguably the confused state is partly caused by the backend server not closing
the request after the "400" errors, but it *is* caused by apache
misunderstanding the meaning of "Expect: 100-continue".

This is the apache configuration snipped used in this experiment:

 <Location /some/path/>
  ProxyPass http://localhost:1234/path/
  ProxyPassReverse http://localhost:1234/path/
  Order allow,deny
  Allow from all
  Deny from none
  SetEnv proxy-interim-response RFC
  SetEnv proxy-sendchunked 1

And FYI, this is the start of the actual, captured request from the client:

    PUT /kmx/pavis2.3/upload/ecc022ad63f16b27bff57bfc9cfa3f7bd2085dba HTTP/1.1
    Host: localhost
    Accept-Encoding: identity
    User-Agent: Treparel KMX Patent Analytics suite/2.2.90
    Content-Type: application/ms-excel; filename="%2Fhome%2Fivo%2Fsvn.etc.xls"
    Transfer-Encoding: chunked
    Expect: 100-continue

Response from apache:

    HTTP/1.1 100 Continue

Body sent by the client:

    (and so on, using chunked encoding).

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
Package: apache2.2-common 2.2.11-2ubuntu2.2
 PATH=(custom, user)
SourcePackage: apache2
Uname: Linux 2.6.28-14-generic x86_64

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