httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 44952] New: FIN packets change port with mod_proxy
Date Wed, 07 May 2008 20:35:42 GMT

           Summary: FIN packets change port with mod_proxy
           Product: Apache httpd-2
           Version: 2.2.3
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_proxy

The problem is that when I'm going through the mod_proxy instance, the FIN
packets to close the TCP session get sent from a *different* source port than
the rest of the TCP transaction.  Thus both hosts gets confused, packets are
dropped and I cannot complete a transaction (e.g. submit FORM data).

# cat /etc/redhat-release ; uname -ip
CentOS release 5 (Final)
i686 i386

# httpd -v
Server version: Apache/2.2.3
Server built:   Jan 15 2008 20:33:30

Here's my test mod_proxy config...

<VirtualHost *>
   ServerName scmoseman
   ProxyRequests Off
   <Proxy *>
       Order deny,allow
       Allow from all
   ProxyPass / http://remotehost:8000/path/
   ProxyPassReverse / http://remotehost:8000/path/
   <Location />
       Order allow,deny
       Allow from all
   RewriteEngine On
   RewriteCond %{REQUEST_URI} ^/path/(.*)
   RewriteRule ^/path/(.*) /$1 [R]

An example of the problem:  When I attempt to login to the website, the entire
transaction is done through the source port 3965.  When it comes time for the
FIN ACK to close the connection, it's going out on source port 4476. 
remotehost asks for a RST, but since its on a different port its rejected.  And
I'm unable to login to the website.  (Just viewing the website in read-only
mode works fine.)

When I attempt the same thing directly using a local web browser and going to
the remotehost URL direct, the entire TCP connection uses a single source port
(including the FIN ACK session).

It does not matter if I use "remotehost" or "" when
referencing the website.  The problem exists either way.


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