mod_proxy_http violates RFC and common sense

Bug #413449 reported by Ivo Timmermans
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Apache2 Web Server
Fix Released
Medium
apache2 (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

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 header:

   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
 </Location>

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:

    19000
    (and so on, using chunked encoding).

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
Package: apache2.2-common 2.2.11-2ubuntu2.2
ProcEnviron:
 SHELL=/bin/zsh
 PATH=(custom, user)
 LC_COLLATE=C
 LANG=nl_NL.UTF-8
 LC_CTYPE=nl_NL.UTF-8
SourcePackage: apache2
Uname: Linux 2.6.28-14-generic x86_64

Revision history for this message
Ivo Timmermans (ivo) wrote :
Revision history for this message
Chuck Short (zulcss) wrote :

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at:

https://issues.apache.org/bugzilla/show_bug.cgi?id=47810

Changed in apache2 (Ubuntu):
status: New → Triaged
Changed in apache2:
status: Unknown → Confirmed
Chuck Short (zulcss)
Changed in apache2 (Ubuntu):
importance: Undecided → Wishlist
Revision history for this message
Chuck Short (zulcss) wrote :

This should be fixed in lucid. If it isnt please re-open.

chuck

Changed in apache2 (Ubuntu):
status: Triaged → Fix Released
Changed in apache2:
importance: Unknown → Medium
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.