From stalker at altlinux.ru Wed Aug 5 18:57:54 2015 From: stalker at altlinux.ru (Anton Gorlov) Date: Wed, 5 Aug 2015 19:57:54 +0300 Subject: [mpm-itk] MaxClientsVhost reached Message-ID: <55C24092.7090203@altlinux.ru> Hi. I'm using scheme internet - nginx - apache-itk in apache-itk using MaxClientsVhost options. Some random time on random sites i get error "MaxClientsVhost reached for site.ru, refusing client. " but no active connectios for site is running. I restart nginx/ block external trafic from internet with iptables. netstat show no active connections to apache/ no time_wait connections but ITK show MaxClientsVhost reached apache2-mpm-itk 2.2.22 from debian wheezy, Server version: Apache/2.2.22 (Debian) Server built: Sep 28 2013 16:43:15 Server's Module Magic Number: 20051115:30 Server loaded: APR 1.4.6, APR-Util 1.4.1 Compiled using: APR 1.4.6, APR-Util 1.4.1 Architecture: 64-bit Server MPM: ITK threaded: no forked: yes (variable process count) Server compiled with.... -D APACHE_MPM_DIR="server/mpm/experimental/itk" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/etc/apache2" -D SUEXEC_BIN="/usr/lib/apache2/suexec" -D DEFAULT_PIDLOG="/var/run/apache2.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="/var/run/apache2/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="mime.types" -D SERVER_CONFIG_FILE="apache2.conf" From sgunderson at bigfoot.com Wed Aug 5 21:13:25 2015 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Wed, 5 Aug 2015 21:13:25 +0200 Subject: [mpm-itk] MaxClientsVhost reached In-Reply-To: <55C24092.7090203@altlinux.ru> References: <55C24092.7090203@altlinux.ru> Message-ID: <20150805191325.GA5084@sesse.net> On Wed, Aug 05, 2015 at 07:57:54PM +0300, Anton Gorlov wrote: > Some random time on random sites i get error "MaxClientsVhost reached > for site.ru, refusing client. " > but no active connectios for site is running. > I restart nginx/ block external trafic from internet with iptables. > netstat show no active connections to apache/ no time_wait connections Take a look in the scoreboard and see what it says. IIRC mod_status will let you inspect it. /* Steinar */ -- Homepage: http://www.sesse.net/ From stalker at altlinux.ru Wed Aug 5 21:29:37 2015 From: stalker at altlinux.ru (Anton Gorlov) Date: Wed, 5 Aug 2015 22:29:37 +0300 Subject: [mpm-itk] MaxClientsVhost reached In-Reply-To: <20150805191325.GA5084@sesse.net> References: <55C24092.7090203@altlinux.ru> <20150805191325.GA5084@sesse.net> Message-ID: <55C26421.8090202@altlinux.ru> 05.08.2015 22:13, Steinar H. Gunderson ?????: > Take a look in the scoreboard and see what it says. IIRC mod_status will let > you inspect it. > > /* Steinar */ mod_status show work global values or per vhosts (show different value per different vhosts)? From sgunderson at bigfoot.com Wed Aug 5 21:37:05 2015 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Wed, 5 Aug 2015 21:37:05 +0200 Subject: [mpm-itk] MaxClientsVhost reached In-Reply-To: <55C26421.8090202@altlinux.ru> References: <55C24092.7090203@altlinux.ru> <20150805191325.GA5084@sesse.net> <55C26421.8090202@altlinux.ru> Message-ID: <20150805193705.GA13105@sesse.net> On Wed, Aug 05, 2015 at 10:29:37PM +0300, Anton Gorlov wrote: > mod_status show work global values or per vhosts (show different value > per different vhosts)? mod_status shows, among other things, the scoreboard (the list of what all the Apache children are doing). This is what mpm-itk uses to determine how many servers are currently serving a given vhost. /* Steinar */ -- Homepage: http://www.sesse.net/ From stalker at altlinux.ru Thu Aug 6 12:19:10 2015 From: stalker at altlinux.ru (Anton Gorlov) Date: Thu, 6 Aug 2015 13:19:10 +0300 Subject: [mpm-itk] MaxClientsVhost reached In-Reply-To: <20150805193705.GA13105@sesse.net> References: <55C24092.7090203@altlinux.ru> <20150805191325.GA5084@sesse.net> <55C26421.8090202@altlinux.ru> <20150805193705.GA13105@sesse.net> Message-ID: <55C3349E.4070506@altlinux.ru> It show more connections to site. but it ghost connections. tcpdump and some other tool not show active connections from this source. 56-2 3174 0/36/2203 G 0.26 17354 0 0.0 0.08 10.01 xx.yy.14.14 site.name GET /vk_api/vk_post_new_action.php?_=1438834362438 HTTP/1.0 63-2 5682 0/40/2078 G 0.11 17092 0 0.0 2.48 13.58 xx.yy.14.14 site.name POST /parser_baza/img_new/parser.php HTTP/1.0 84-2 4218 0/38/2137 G 0.86 17317 0 0.0 0.07 6.62 xx.yy.14.14 site.name GET /vk_api/vk_post_new_action.php?_=1438834362439 HTTP/1.0 85-2 3374 0/49/2153 G 0.29 17043 0 0.0 0.12 14.47 xx.yy.14.14 site.name GET /vk_api/vk_post_new_action.php?_=1438834362441 HTTP/1.0 86-2 4219 0/32/2028 G 0.00 17334 0 0.0 0.28 6.98 xx.yy.14.14 site.name POST /parser_baza/img_new/parser.php HTTP/1.0 107-2 4426 0/47/1946 G 0.15 17068 0 0.0 0.13 6.11 xx.yy.14.14 site.name GET /vk_api/vk_post_new_action.php?_=1438834362440 HTTP/1.0 111-2 5353 0/15/1859 G 0.10 17643 0 0.0 0.06 7.51 xx.yy.14.14 site.name POST /parser_baza/img_new/parser.php HTTP/1.0 121-2 4429 0/34/1484 G 0.00 17343 0 0.0 0.11 4.20 xx.yy.14.14 site.name POST /parser_baza/img_new/parser.php HTTP/1.0 133-2 28498 0/35/285 G 0.15 17995 0 0.0 0.11 0.82 xx.yy.14.14 site.name POST /parser_b root at sulfur:~# netstat -nap | grep xx.yy.14.14 root at sulfur:~# and I add to firewall root at sulfur:~# iptables-save -c | grep xx.yy.14.14 [78:4056] -A INPUT -s xx.yy.14.14/32 -j DROP 05.08.2015 22:37, Steinar H. Gunderson ?????: > On Wed, Aug 05, 2015 at 10:29:37PM +0300, Anton Gorlov wrote: >> mod_status show work global values or per vhosts (show different value >> per different vhosts)? > mod_status shows, among other things, the scoreboard (the list of what all > the Apache children are doing). This is what mpm-itk uses to determine how > many servers are currently serving a given vhost. > > /* Steinar */ From sgunderson at bigfoot.com Thu Aug 6 12:28:09 2015 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Thu, 6 Aug 2015 12:28:09 +0200 Subject: [mpm-itk] MaxClientsVhost reached In-Reply-To: <55C3349E.4070506@altlinux.ru> References: <55C24092.7090203@altlinux.ru> <20150805191325.GA5084@sesse.net> <55C26421.8090202@altlinux.ru> <20150805193705.GA13105@sesse.net> <55C3349E.4070506@altlinux.ru> Message-ID: <20150806102809.GA20860@sesse.net> On Thu, Aug 06, 2015 at 01:19:10PM +0300, Anton Gorlov wrote: > It show more connections to site. but it ghost connections. tcpdump and > some other tool not show active connections from this source. If Apache thinks there are connections in the scoreboard where there's not, it's an Apache bug and there's nothing mpm-itk can do. /* Steinar */ -- Homepage: http://www.sesse.net/ From mysql.jorge at decimal.pt Wed Aug 12 14:58:05 2015 From: mysql.jorge at decimal.pt (Jorge Bastos) Date: Wed, 12 Aug 2015 13:58:05 +0100 Subject: [mpm-itk] Debian package Message-ID: Hi, I'd like to upgrade my apache version to the latest available, but can't due to mpm-itk package that still is on version 2.4.10. Is it possible to upgrade it? I suppose that you're the package maint. Thanks in advanced, The following packages have unmet dependencies: apache2-mpm-itk : Depends: apache2 (= 2.4.10-11) but 2.4.16-2 is to be installed -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgunderson at bigfoot.com Wed Aug 12 15:07:59 2015 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Wed, 12 Aug 2015 15:07:59 +0200 Subject: [mpm-itk] Debian package In-Reply-To: References: Message-ID: <20150812130759.GA28836@sesse.net> On Wed, Aug 12, 2015 at 01:58:05PM +0100, Jorge Bastos wrote: > I'd like to upgrade my apache version to the latest available, but can't due > to mpm-itk package that still is on version 2.4.10. > > > > Is it possible to upgrade it? If you look at the apache2-mpm-itk package description, this will probably answer your question (I removed some irrelevant fields): Package: apache2-mpm-itk Version: 2.4.10-10 Depends: apache2 (= 2.4.10-10), libapache2-mpm-itk Maintainer: Debian Apache Maintainers Description-en: transitional itk MPM package for apache2 This is a transitional package to apache2 for users of apache2-mpm-itk and can be safely removed after the installation is complete. > I suppose that you're the package maint. No. See above. /* Steinar */ -- Homepage: http://www.sesse.net/ From mysql.jorge at decimal.pt Wed Aug 12 15:58:42 2015 From: mysql.jorge at decimal.pt (Jorge Bastos) Date: Wed, 12 Aug 2015 14:58:42 +0100 Subject: [mpm-itk] Debian package In-Reply-To: <20150812130759.GA28836@sesse.net> References: <20150812130759.GA28836@sesse.net> Message-ID: Steinar, Ok you're right. Do you have any influence on them? > -----Original Message----- > From: Steinar H. Gunderson [mailto:sgunderson at bigfoot.com] > Sent: quarta-feira, 12 de Agosto de 2015 14:08 > To: Jorge Bastos > Cc: mpm-itk at err.no > Subject: Re: [mpm-itk] Debian package > > On Wed, Aug 12, 2015 at 01:58:05PM +0100, Jorge Bastos wrote: > > I'd like to upgrade my apache version to the latest available, but > > can't due to mpm-itk package that still is on version 2.4.10. > > > > > > > > Is it possible to upgrade it? > > If you look at the apache2-mpm-itk package description, this will > probably answer your question (I removed some irrelevant fields): > > Package: apache2-mpm-itk > Version: 2.4.10-10 > Depends: apache2 (= 2.4.10-10), libapache2-mpm-itk > Maintainer: Debian Apache Maintainers apache at lists.debian.org> > Description-en: transitional itk MPM package for apache2 > This is a transitional package to apache2 for users of apache2-mpm- > itk and > can be safely removed after the installation is complete. > > > I suppose that you're the package maint. > > No. See above. > > /* Steinar */ > -- > Homepage: http://www.sesse.net/ From sgunderson at bigfoot.com Wed Aug 12 16:02:14 2015 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Wed, 12 Aug 2015 16:02:14 +0200 Subject: [mpm-itk] Debian package In-Reply-To: References: <20150812130759.GA28836@sesse.net> Message-ID: <20150812140214.GA6796@sesse.net> On Wed, Aug 12, 2015 at 02:58:42PM +0100, Jorge Bastos wrote: > Do you have any influence on them? How is it relevant? Remove the package. You don't need it. What you need is libapache2-mpm-itk. /* Steinar */ -- Homepage: http://www.sesse.net/ From roehner at fs.tum.de Thu Aug 13 00:33:50 2015 From: roehner at fs.tum.de (=?UTF-8?B?S2lsaWFuIFLDtmhuZXI=?=) Date: Thu, 13 Aug 2015 00:33:50 +0200 Subject: [mpm-itk] Problem with AssignUserIDExpr Message-ID: <55CBC9CE.7000707@fs.tum.de> Hi everybody, on my apache 2.4.10 (Debian) with libapache2-mpm-itk 2.4.7-02-1.1 installed, I'm trying to get AssignUserIDExpr running in order to run the user-homes (/~foo) with different permissions (as mentioned on the website of the module). The AssignUserID directive works quite well for me. However, AssignUserIDExpr is not working as expected. I've broken it down to the following, not working example: SetEnv ITKUID www-bar AssignUserIDExpr %{reqenv:ITKUID} When accessing the webserver, I get in my error.log: [mpm_itk:error] [pid 13916] AssignUserIDExpr returned '', which is not a valid user name However, setting AssignUserIDExpr explicitely to a string is working. So the problem seems to be something with the env-variables. Can anybody help me here? By the way, in the process of trying to find the source of the problem, I found a little bug in mpm_itk.c, line 338. Here, "wanted_username" should be replaced with "wanted_groupname". Best, Kilian From ssmeenk at freshdot.net Mon Aug 17 16:51:46 2015 From: ssmeenk at freshdot.net (Sander Smeenk) Date: Mon, 17 Aug 2015 16:51:46 +0200 Subject: [mpm-itk] unable to check htaccess file In-Reply-To: References: <20140623194301.GE3202@pvv.ntnu.no> <20140624155346.GA15725@sesse.net> Message-ID: <20150817145146.GI2518@dot.dmz.freshdot.net> Quoting James Devine (fxmulder at gmail.com): > Gotcha, well I've traced the error to a call to ap_run_open_htaccess inside > apache itself. getuid() returns 33 (www-data) right before this call [ .. ] I've stumbled upon this thread when looking for answers to this exact situation: I've upgraded one of our test servers to 14.04, site content is on NFS (i'm not using root_squash and the NFS server is a NetApp filer), and now Apache fails to serve files unless i set the +x bit on all parent directories. It doesn't really seem like there has been a conclusion to this thread, other than it is caused by the new CAP(abilities) introduced. James, i CC'd you in this message in fear of you not being subscribed to this list anymore, did you manage to find a workaround other than setting +x bits on all parent dirs? Not sure why this new CAP_DAC_READ_SEARCH-foo was introduced, probably to prevent a -DBIG_SECURITY_HOLE, but putting +x bits on all parent dirs also introduces security risks, since users on my platform could guess that a site runs wordpress and has a htdocs/wp-config.php or something. It's a big file permission mess like this. ;) Curious to hear from you! Regards, -Sndr. -- | Schr?dingers cat walks into a bar and doesn't. | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 From allyn at hp.com Mon Aug 17 16:59:31 2015 From: allyn at hp.com (Fratkin, Allyn) Date: Mon, 17 Aug 2015 14:59:31 +0000 Subject: [mpm-itk] unable to check htaccess file In-Reply-To: <20150817145146.GI2518@dot.dmz.freshdot.net> References: <20140623194301.GE3202@pvv.ntnu.no> <20140624155346.GA15725@sesse.net> <20150817145146.GI2518@dot.dmz.freshdot.net> Message-ID: <3F2C716F732D504F96AF3ECE90DF4D848A83F54F@G4W3233.americas.hpqcorp.net> We ran into the exact same issue (.htacess files being read as root while using NFS with root_squash) and were able to work around it using ACLs to allow +x permission only for user nfsnobody. Better than allowing +x for everyone. We used: setfacl -m u:nfsnobody:--x dirname Certainly hope this bug is able to be fixed at some point. -- Allyn Fratkin allyn at hp.com Hewlett-Packard Company http://www.fratkin.com/ -----Original Message----- From: mpm-itk [mailto:mpm-itk-bounces at err.no] On Behalf Of Sander Smeenk Sent: Monday, August 17, 2015 7:52 AM To: mpm-itk at err.no Subject: Re: [mpm-itk] unable to check htaccess file Quoting James Devine (fxmulder at gmail.com): > Gotcha, well I've traced the error to a call to ap_run_open_htaccess inside > apache itself. getuid() returns 33 (www-data) right before this call [ .. ] I've stumbled upon this thread when looking for answers to this exact situation: I've upgraded one of our test servers to 14.04, site content is on NFS (i'm not using root_squash and the NFS server is a NetApp filer), and now Apache fails to serve files unless i set the +x bit on all parent directories. It doesn't really seem like there has been a conclusion to this thread, other than it is caused by the new CAP(abilities) introduced. James, i CC'd you in this message in fear of you not being subscribed to this list anymore, did you manage to find a workaround other than setting +x bits on all parent dirs? Not sure why this new CAP_DAC_READ_SEARCH-foo was introduced, probably to prevent a -DBIG_SECURITY_HOLE, but putting +x bits on all parent dirs also introduces security risks, since users on my platform could guess that a site runs wordpress and has a htdocs/wp-config.php or something. It's a big file permission mess like this. ;) Curious to hear from you! Regards, -Sndr. -- | Schr?dingers cat walks into a bar and doesn't. | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 _______________________________________________ mpm-itk mailing list mpm-itk at err.no http://lists.err.no/mailman/listinfo/mpm-itk From ssmeenk at freshdot.net Mon Aug 17 17:13:40 2015 From: ssmeenk at freshdot.net (Sander Smeenk) Date: Mon, 17 Aug 2015 17:13:40 +0200 Subject: [mpm-itk] unable to check htaccess file In-Reply-To: <3F2C716F732D504F96AF3ECE90DF4D848A83F54F@G4W3233.americas.hpqcorp.net> References: <20140623194301.GE3202@pvv.ntnu.no> <20140624155346.GA15725@sesse.net> <20150817145146.GI2518@dot.dmz.freshdot.net> <3F2C716F732D504F96AF3ECE90DF4D848A83F54F@G4W3233.americas.hpqcorp.net> Message-ID: <20150817151340.GA26354@dot.dmz.freshdot.net> Quoting Fratkin, Allyn (allyn at hp.com): > We ran into the exact same issue (.htacess files being read as root > while using NFS with root_squash) and were able to work around it > using ACLs to allow +x permission only for user nfsnobody. Better > than allowing +x for everyone. This is *not* the exact same issue. I'm not using root squash, and i see Apache trying to access the dirs with uid 33/www-data, like James Devine shows in his earlier posts to the list. > We used: setfacl -m u:nfsnobody:--x dirname That wont work on NFS-mounted data. Thanks, -Sndr. -- | Why is the third hand on the watch called a second hand? | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 From allyn at hp.com Mon Aug 17 17:25:45 2015 From: allyn at hp.com (Fratkin, Allyn) Date: Mon, 17 Aug 2015 15:25:45 +0000 Subject: [mpm-itk] unable to check htaccess file In-Reply-To: <20150817151340.GA26354@dot.dmz.freshdot.net> References: <20140623194301.GE3202@pvv.ntnu.no> <20140624155346.GA15725@sesse.net> <20150817145146.GI2518@dot.dmz.freshdot.net> <3F2C716F732D504F96AF3ECE90DF4D848A83F54F@G4W3233.americas.hpqcorp.net> <20150817151340.GA26354@dot.dmz.freshdot.net> Message-ID: <3F2C716F732D504F96AF3ECE90DF4D848A83F5EF@G4W3233.americas.hpqcorp.net> Apologies, I wasn't able to find the archives of this mailing list and I just recently joined so I am coming in in the middle of the conversation. Odd that you're seeing the exact opposite of what we're seeing. We're using root_squash, and definitely seeing .htaccess files read as root. Not as either the default user set in the httpd.conf file (apache) or the user set in each virtual host. We're using the httpd-itk-2.2.22-7.el6.x86_64 rpm from EPEL. BTW, ACLs certainly do work over NFS in our RHEL6 environment. As I said we're using them successfully. The only thing we had to do to make them work was mounting the volumes on the NFS servers with acl option. Nothing special needed on the clients. -- Allyn Fratkin allyn at hp.com Hewlett-Packard Company http://www.fratkin.com/ -----Original Message----- From: mpm-itk [mailto:mpm-itk-bounces at err.no] On Behalf Of Sander Smeenk Sent: Monday, August 17, 2015 8:14 AM To: mpm-itk at err.no Subject: Re: [mpm-itk] unable to check htaccess file Quoting Fratkin, Allyn (allyn at hp.com): > We ran into the exact same issue (.htacess files being read as root > while using NFS with root_squash) and were able to work around it > using ACLs to allow +x permission only for user nfsnobody. Better > than allowing +x for everyone. This is *not* the exact same issue. I'm not using root squash, and i see Apache trying to access the dirs with uid 33/www-data, like James Devine shows in his earlier posts to the list. > We used: setfacl -m u:nfsnobody:--x dirname That wont work on NFS-mounted data. Thanks, -Sndr. -- | Why is the third hand on the watch called a second hand? | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 _______________________________________________ mpm-itk mailing list mpm-itk at err.no http://lists.err.no/mailman/listinfo/mpm-itk From ssmeenk at freshdot.net Mon Aug 17 17:30:54 2015 From: ssmeenk at freshdot.net (Sander Smeenk) Date: Mon, 17 Aug 2015 17:30:54 +0200 Subject: [mpm-itk] unable to check htaccess file In-Reply-To: <3F2C716F732D504F96AF3ECE90DF4D848A83F5EF@G4W3233.americas.hpqcorp.net> References: <20140623194301.GE3202@pvv.ntnu.no> <20140624155346.GA15725@sesse.net> <20150817145146.GI2518@dot.dmz.freshdot.net> <3F2C716F732D504F96AF3ECE90DF4D848A83F54F@G4W3233.americas.hpqcorp.net> <20150817151340.GA26354@dot.dmz.freshdot.net> <3F2C716F732D504F96AF3ECE90DF4D848A83F5EF@G4W3233.americas.hpqcorp.net> Message-ID: <20150817153054.GB26354@dot.dmz.freshdot.net> Quoting Fratkin, Allyn (allyn at hp.com): > Apologies, I wasn't able to find the archives of this mailing list and > I just recently joined so I am coming in in the middle of the > conversation. Ah. That explains. The archives [http://lists.err.no/pipermail/mpm-itk/] show 403 Forbidden, might well be the same issue as we're discussing. ;-)) > Odd that you're seeing the exact opposite of what we're seeing. We're > using root_squash, and definitely seeing .htaccess files read as root. > Not as either the default user set in the httpd.conf file (apache) or > the user set in each virtual host. We're using the > httpd-itk-2.2.22-7.el6.x86_64 rpm from EPEL. The issue James and i are having is new with Apache 2.4.x. Your 2.2 install runs a number of Apache processes all as root, in 2.4 it runs one process as root and a number of processes as www-data (with special capabilities set so it can setuid/setgid). > BTW, ACLs certainly do work over NFS in our RHEL6 environment. As I > said we're using them successfully. The only thing we had to do to > make them work was mounting the volumes on the NFS servers with acl > option. Nothing special needed on the clients. Perhaps this is something supported when NFS-server is on Linux? Not sure if a NetApp filer can do the same, but even so, the problem you are having is different to mine. I get operation not permitted on setfacl calls on the NFS mount. Regards, -Sndr. -- | I doubt, therefore I might be. | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 From allyn at hp.com Mon Aug 17 17:38:23 2015 From: allyn at hp.com (Fratkin, Allyn) Date: Mon, 17 Aug 2015 15:38:23 +0000 Subject: [mpm-itk] unable to check htaccess file In-Reply-To: <20150817153054.GB26354@dot.dmz.freshdot.net> References: <20140623194301.GE3202@pvv.ntnu.no> <20140624155346.GA15725@sesse.net> <20150817145146.GI2518@dot.dmz.freshdot.net> <3F2C716F732D504F96AF3ECE90DF4D848A83F54F@G4W3233.americas.hpqcorp.net> <20150817151340.GA26354@dot.dmz.freshdot.net> <3F2C716F732D504F96AF3ECE90DF4D848A83F5EF@G4W3233.americas.hpqcorp.net> <20150817153054.GB26354@dot.dmz.freshdot.net> Message-ID: <3F2C716F732D504F96AF3ECE90DF4D848A83F634@G4W3233.americas.hpqcorp.net> Thank you for the information. If anyone could fix the archives it would be much appreciated. So "reading .htaccess files as root" is a known issue with 2.2? -- Allyn Fratkin allyn at hp.com Hewlett-Packard Company http://www.fratkin.com/ -----Original Message----- From: mpm-itk [mailto:mpm-itk-bounces at err.no] On Behalf Of Sander Smeenk Sent: Monday, August 17, 2015 8:31 AM To: mpm-itk at err.no Subject: Re: [mpm-itk] unable to check htaccess file Quoting Fratkin, Allyn (allyn at hp.com): > Apologies, I wasn't able to find the archives of this mailing list and > I just recently joined so I am coming in in the middle of the > conversation. Ah. That explains. The archives [http://lists.err.no/pipermail/mpm-itk/] show 403 Forbidden, might well be the same issue as we're discussing. ;-)) > Odd that you're seeing the exact opposite of what we're seeing. We're > using root_squash, and definitely seeing .htaccess files read as root. > Not as either the default user set in the httpd.conf file (apache) or > the user set in each virtual host. We're using the > httpd-itk-2.2.22-7.el6.x86_64 rpm from EPEL. The issue James and i are having is new with Apache 2.4.x. Your 2.2 install runs a number of Apache processes all as root, in 2.4 it runs one process as root and a number of processes as www-data (with special capabilities set so it can setuid/setgid). > BTW, ACLs certainly do work over NFS in our RHEL6 environment. As I > said we're using them successfully. The only thing we had to do to > make them work was mounting the volumes on the NFS servers with acl > option. Nothing special needed on the clients. Perhaps this is something supported when NFS-server is on Linux? Not sure if a NetApp filer can do the same, but even so, the problem you are having is different to mine. I get operation not permitted on setfacl calls on the NFS mount. Regards, -Sndr. -- | I doubt, therefore I might be. | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 _______________________________________________ mpm-itk mailing list mpm-itk at err.no http://lists.err.no/mailman/listinfo/mpm-itk From alex.hha at gmail.com Wed Aug 26 17:43:22 2015 From: alex.hha at gmail.com (Alex Domoradov) Date: Wed, 26 Aug 2015 18:43:22 +0300 Subject: [mpm-itk] Is there any possibility to run several versions of php simultaneously? Message-ID: For last few years I have used mpm-itk with perdir-regex patch without any problems. The only thing that I have missed - possibility to run 2/3 version oh php at the same time. When I try to run cgi version of php I got the following error [Wed Aug 26 18:21:49 2015] [emerg] [client xxx.xxx.xxx.xxx] (13)Permission denied: mod_fcgid: can't lock process table in pid 5545 Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at frankieandshadow.com Thu Aug 27 13:06:19 2015 From: david at frankieandshadow.com (David Earl) Date: Thu, 27 Aug 2015 11:06:19 +0000 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari Message-ID: Hi, I've just joined this mailing list because I've been using mpm-itk successfully for some time, but after upgrading to Debian 8 Jessie on several servers, which includes Apache 2.4.10 (previously 2.2) it no longer works properly with SSL sites. Before I realised it was mpm-itk (which I've now confirmed by uninstalling and reinstalling) I posted a question on serverfault.com, so I won't repeat it all here: http://serverfault.com/questions/716330/keepalive-in-apache-2-4-interfering-with-form-submissions Looking back over recent posts on this mailing list, I suspect it is likely this is the same problem as this thread: http://lists.err.no/pipermail/mpm-itk/2015-July/000865.html Something odd happened about getting subscribed to this list so I emailed Steinar directly, and prepared a VirtualBox VDI which has a completely reproducible test case with IE11; but it also fails on iOS Safari. If anyone else would like a copy of this then I'd be delighted to send it (it's a little under 2GB). I have to say, despite having prepared a completely reproducible test case, and this problem effectively rendering mpm-itk useless for SSL sites with Apache 2.4, Steinar was not willing to look at it. Because it's IE, you have to use a Windows client (like most real world users!) and he seemed to be reluctant to touch Windows. It is possible there is some setting I have to change that would fix the problem, but I have no idea what and I've tried all the obvious things. Sadly, as it's been very useful up to now, I have to conclude therefore that if no one else is helping with mpm-itk then it is no longer supported and this showstopper and I should try something else. Is anyone else working on it? Unfortunately suPHP also seems not to be supported any more. I may have to use fcgi, but it's a pain to move over to that. I'd much rather have a working mpm-itk if possible. Should I persist or am I flogging a dead horse? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From knut at auvor.no Thu Aug 27 19:06:35 2015 From: knut at auvor.no (Knut Auvor Grythe) Date: Thu, 27 Aug 2015 19:06:35 +0200 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: References: Message-ID: <20150827170634.GW8617@pvv.ntnu.no> On Thu, Aug 27, 2015 at 11:06:19AM +0000, David Earl wrote: > I have to say, despite having prepared a completely reproducible test case, > and this problem effectively rendering mpm-itk useless for SSL sites with > Apache 2.4, Steinar was not willing to look at it. Because it's IE, you > have to use a Windows client (like most real world users!) and he seemed to > be reluctant to touch Windows. Lots of people are using mpm-itk with SSL and Windows clients, so this is probably some obscure configuration issue. Steinar may be reluctant to touch Windows, but it may also very well be that he doesn't have the time (and probably not the interest) to teach himself how to debug IE in order to figure out your browser-specific issue. All that being said, since it seems from your description that the issue is that IE never even tries to contact the server again, perhaps you could compare the output from your old, working setup with what you're seeing now? Seeing what's different may give a hint about what to look for. If you determine a difference in behaviow between the old server and the new one, it will be a lot easier for both yourself and anyone else to figure out what's going on. -- Knut Auvor From david at frankieandshadow.com Thu Aug 27 20:09:46 2015 From: david at frankieandshadow.com (David Earl) Date: Thu, 27 Aug 2015 18:09:46 +0000 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: <20150827170634.GW8617@pvv.ntnu.no> References: <20150827170634.GW8617@pvv.ntnu.no> Message-ID: > compare the output Compare what output? That's part of the problem, there is no output now. There's nothing of any help in any log files, server or client. I could certainly set up an equivalent Apache 2.2 with Debian 7, but what would I be looking for specifically? > your browser-specific issue well, it happens in at least two mainstream widely used browsers making up about a third or more of the market! The test with Kilian's server demonstrates it's not just my server set up either, and having installed one from scratch yesterday, it happens with a minimum of change to the default settings as well. I've tried pretty much every combination of settings I can. > Lots of people are using mpm-itk with SSL and Windows clients Sure, I was too. And the vast majority of the world uses Windows clients, albeit maybe only a third now use IE. The difference seems to be the upgrade to Apache 2.4. Do you know of a site that runs mpm-itk, SSL, Apache 2.4 (and with KeepAlive on, as most would be) and has a publicly accessible file upload page that I can compare with? Any Wordpress site with public registration would do, for example. David On Thu, 27 Aug 2015 at 18:06 Knut Auvor Grythe wrote: > On Thu, Aug 27, 2015 at 11:06:19AM +0000, David Earl wrote: > > I have to say, despite having prepared a completely reproducible test > case, > > and this problem effectively rendering mpm-itk useless for SSL sites with > > Apache 2.4, Steinar was not willing to look at it. Because it's IE, you > > have to use a Windows client (like most real world users!) and he seemed > to > > be reluctant to touch Windows. > > Lots of people are using mpm-itk with SSL and Windows clients, so this > is probably some obscure configuration issue. Steinar may be reluctant > to touch Windows, but it may also very well be that he doesn't have the > time (and probably not the interest) to teach himself how to debug IE in > order to figure out your browser-specific issue. > > All that being said, since it seems from your description that the issue > is that IE never even tries to contact the server again, perhaps you > could compare the output from your old, working setup with what you're > seeing now? Seeing what's different may give a hint about what to look > for. If you determine a difference in behaviow between the old server > and the new one, it will be a lot easier for both yourself and anyone > else to figure out what's going on. > > -- > Knut Auvor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From remko at freebsd.org Thu Aug 27 20:14:40 2015 From: remko at freebsd.org (Remko Lodder) Date: Thu, 27 Aug 2015 20:14:40 +0200 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: References: <20150827170634.GW8617@pvv.ntnu.no> Message-ID: <70D554A5-4B98-40CA-9972-89FB881F47D2@freebsd.org> The problem is mostly with https and doing a POST request. At work we have this same issue as well as on my private FreeBSD systems. (Read logging in to some application or submitting a form has this result). Cheers, Remko Lodder /* sent from my phone and thus brief and to the point *\ > Op 27 aug. 2015 om 20:09 heeft David Earl het volgende geschreven: > > > compare the output > > Compare what output? That's part of the problem, there is no output now. There's nothing of any help in any log files, server or client. I could certainly set up an equivalent Apache 2.2 with Debian 7, but what would I be looking for specifically? > > > your browser-specific issue > > well, it happens in at least two mainstream widely used browsers making up about a third or more of the market! The test with Kilian's server demonstrates it's not just my server set up either, and having installed one from scratch yesterday, it happens with a minimum of change to the default settings as well. I've tried pretty much every combination of settings I can. > > > Lots of people are using mpm-itk with SSL and Windows clients > > Sure, I was too. And the vast majority of the world uses Windows clients, albeit maybe only a third now use IE. The difference seems to be the upgrade to Apache 2.4. > > Do you know of a site that runs mpm-itk, SSL, Apache 2.4 (and with KeepAlive on, as most would be) and has a publicly accessible file upload page that I can compare with? Any Wordpress site with public registration would do, for example. > > David > > >> On Thu, 27 Aug 2015 at 18:06 Knut Auvor Grythe wrote: >> On Thu, Aug 27, 2015 at 11:06:19AM +0000, David Earl wrote: >> > I have to say, despite having prepared a completely reproducible test case, >> > and this problem effectively rendering mpm-itk useless for SSL sites with >> > Apache 2.4, Steinar was not willing to look at it. Because it's IE, you >> > have to use a Windows client (like most real world users!) and he seemed to >> > be reluctant to touch Windows. >> >> Lots of people are using mpm-itk with SSL and Windows clients, so this >> is probably some obscure configuration issue. Steinar may be reluctant >> to touch Windows, but it may also very well be that he doesn't have the >> time (and probably not the interest) to teach himself how to debug IE in >> order to figure out your browser-specific issue. >> >> All that being said, since it seems from your description that the issue >> is that IE never even tries to contact the server again, perhaps you >> could compare the output from your old, working setup with what you're >> seeing now? Seeing what's different may give a hint about what to look >> for. If you determine a difference in behaviow between the old server >> and the new one, it will be a lot easier for both yourself and anyone >> else to figure out what's going on. >> >> -- >> Knut Auvor > _______________________________________________ > mpm-itk mailing list > mpm-itk at err.no > http://lists.err.no/mailman/listinfo/mpm-itk -------------- next part -------------- An HTML attachment was scrubbed... URL: From azurit at pobox.sk Thu Aug 27 20:21:16 2015 From: azurit at pobox.sk (azurit at pobox.sk) Date: Thu, 27 Aug 2015 20:21:16 +0200 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: References: <20150827170634.GW8617@pvv.ntnu.no> Message-ID: <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> >> compare the output > > Compare what output? That's part of the problem, there is no output now. > There's nothing of any help in any log files, server or client. I could > certainly set up an equivalent Apache 2.2 with Debian 7, but what would I > be looking for specifically? Output of the first request (one which comes from the connection which keeps opened because of KeepAlive). As there's no any other data transmitted, the 'problem' must come with first request - if it's really happening and it isn't a problem on your side, there must be something which confuses the browser. And i suggest to debug it with IP address URL so DNS errors can be really ignored. >> your browser-specific issue > > well, it happens in at least two mainstream widely used browsers making up > about a third or more of the market! The test with Kilian's server > demonstrates it's not just my server set up either, and having installed > one from scratch yesterday, it happens with a minimum of change to the > default settings as well. I've tried pretty much every combination of > settings I can. > >> Lots of people are using mpm-itk with SSL and Windows clients > > Sure, I was too. And the vast majority of the world uses Windows clients, > albeit maybe only a third now use IE. The difference seems to be the > upgrade to Apache 2.4. > > Do you know of a site that runs mpm-itk, SSL, Apache 2.4 (and with > KeepAlive on, as most would be) and has a publicly accessible file upload > page that I can compare with? Any Wordpress site with public registration > would do, for example. > > David > > > On Thu, 27 Aug 2015 at 18:06 Knut Auvor Grythe wrote: > >> On Thu, Aug 27, 2015 at 11:06:19AM +0000, David Earl wrote: >> > I have to say, despite having prepared a completely reproducible test >> case, >> > and this problem effectively rendering mpm-itk useless for SSL sites with >> > Apache 2.4, Steinar was not willing to look at it. Because it's IE, you >> > have to use a Windows client (like most real world users!) and he seemed >> to >> > be reluctant to touch Windows. >> >> Lots of people are using mpm-itk with SSL and Windows clients, so this >> is probably some obscure configuration issue. Steinar may be reluctant >> to touch Windows, but it may also very well be that he doesn't have the >> time (and probably not the interest) to teach himself how to debug IE in >> order to figure out your browser-specific issue. >> >> All that being said, since it seems from your description that the issue >> is that IE never even tries to contact the server again, perhaps you >> could compare the output from your old, working setup with what you're >> seeing now? Seeing what's different may give a hint about what to look >> for. If you determine a difference in behaviow between the old server >> and the new one, it will be a lot easier for both yourself and anyone >> else to figure out what's going on. >> >> -- >> Knut Auvor >> From david at frankieandshadow.com Fri Aug 28 00:33:33 2015 From: david at frankieandshadow.com (David Earl) Date: Thu, 27 Aug 2015 22:33:33 +0000 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> Message-ID: A bit more information... The file upload is a red herring [idiom: misleading evidence], I think. It's actually just the timing. It works if you submit the form within 5 seconds, fails between 5 and 60, and works after 60. It's quite hard to select a file in less than 5 seconds, but that's why I thought it was working on the second attempt. Actually, it wasn't, it was just that the file I was choosing was in front of me on the second attempt so it was quick to select. So, that means the ios and IE11 cases are actually much more similar in their symptoms than I thought. Both 5 seconds and 60 are significant. The default KeepAliveTimeout is 5, and IE assumes a minimum of 60 I believe. This discrepancy was supposed to have been dealt with in Apache, which is what the removal of that BrowserMatch directive was all about. But it looks like this isn't the case when mpm-itk is installed, whether it is down to mpm-itk directly, or a side effect. Who closes the socket after the KeepAliveTimeout? Is it mpm-itk? If mpm-itk isn't there, who does it? Did Apache put a fix in the other mpm modules which possibly isn't reflected in mpm-itk? Why is it only SSL? Is it possible that it can't determine something that is browser dependent until it has made the connection, at which time it is then too late to do anything about it? David David -------------- next part -------------- An HTML attachment was scrubbed... URL: From azurit at pobox.sk Fri Aug 28 08:49:41 2015 From: azurit at pobox.sk (azurit at pobox.sk) Date: Fri, 28 Aug 2015 08:49:41 +0200 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> Message-ID: <20150828084941.Horde.K06azQzFH1T-zcQjFhJcjwu@webmail.inetadmin.eu> Can you try setting KeepAliveTimeout to 61? Cit?t David Earl : > A bit more information... > > The file upload is a red herring [idiom: misleading evidence], I think. > It's actually just the timing. It works if you submit the form within 5 > seconds, fails between 5 and 60, and works after 60. > > It's quite hard to select a file in less than 5 seconds, but that's why I > thought it was working on the second attempt. Actually, it wasn't, it was > just that the file I was choosing was in front of me on the second attempt > so it was quick to select. > > So, that means the ios and IE11 cases are actually much more similar in > their symptoms than I thought. > > Both 5 seconds and 60 are significant. The default KeepAliveTimeout is 5, > and IE assumes a minimum of 60 I believe. This discrepancy was supposed to > have been dealt with in Apache, which is what the removal of that > BrowserMatch directive was all about. But it looks like this isn't the case > when mpm-itk is installed, whether it is down to mpm-itk directly, or a > side effect. > > Who closes the socket after the KeepAliveTimeout? Is it mpm-itk? If mpm-itk > isn't there, who does it? Did Apache put a fix in the other mpm modules > which possibly isn't reflected in mpm-itk? > > Why is it only SSL? Is it possible that it can't determine something that > is browser dependent until it has made the connection, at which time it is > then too late to do anything about it? > > David > > > > David From azurit at pobox.sk Fri Aug 28 09:19:35 2015 From: azurit at pobox.sk (azurit at pobox.sk) Date: Fri, 28 Aug 2015 09:19:35 +0200 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: <20150828084941.Horde.K06azQzFH1T-zcQjFhJcjwu@webmail.inetadmin.eu> References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> <20150828084941.Horde.K06azQzFH1T-zcQjFhJcjwu@webmail.inetadmin.eu> Message-ID: <20150828091935.Horde._94a83mBRqccqKG1xjUj1U1@webmail.inetadmin.eu> > Can you try setting KeepAliveTimeout to 61? Just to be sure - i mean KeepAliveTimeout in Apache. > > > > > > > Cit?t David Earl : > >> A bit more information... >> >> The file upload is a red herring [idiom: misleading evidence], I think. >> It's actually just the timing. It works if you submit the form within 5 >> seconds, fails between 5 and 60, and works after 60. >> >> It's quite hard to select a file in less than 5 seconds, but that's why I >> thought it was working on the second attempt. Actually, it wasn't, it was >> just that the file I was choosing was in front of me on the second attempt >> so it was quick to select. >> >> So, that means the ios and IE11 cases are actually much more similar in >> their symptoms than I thought. >> >> Both 5 seconds and 60 are significant. The default KeepAliveTimeout is 5, >> and IE assumes a minimum of 60 I believe. This discrepancy was supposed to >> have been dealt with in Apache, which is what the removal of that >> BrowserMatch directive was all about. But it looks like this isn't the case >> when mpm-itk is installed, whether it is down to mpm-itk directly, or a >> side effect. >> >> Who closes the socket after the KeepAliveTimeout? Is it mpm-itk? If mpm-itk >> isn't there, who does it? Did Apache put a fix in the other mpm modules >> which possibly isn't reflected in mpm-itk? >> >> Why is it only SSL? Is it possible that it can't determine something that >> is browser dependent until it has made the connection, at which time it is >> then too late to do anything about it? >> >> David >> >> >> >> David > > > > > _______________________________________________ > mpm-itk mailing list > mpm-itk at err.no > http://lists.err.no/mailman/listinfo/mpm-itk From david at frankieandshadow.com Fri Aug 28 18:22:57 2015 From: david at frankieandshadow.com (David Earl) Date: Fri, 28 Aug 2015 16:22:57 +0000 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: <20150828091935.Horde._94a83mBRqccqKG1xjUj1U1@webmail.inetadmin.eu> References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> <20150828084941.Horde.K06azQzFH1T-zcQjFhJcjwu@webmail.inetadmin.eu> <20150828091935.Horde._94a83mBRqccqKG1xjUj1U1@webmail.inetadmin.eu> Message-ID: OK, I did that (KeepAliveTimeout 61) originally, and thought it had no effect, but I was trying so many things, perhaps I forgot to restart Apache or IE that time, so missed it. (IE caches the value if you just refresh the page, so you have to restart the browser seemingly). Trying it again now, it does indeed make the problem go away. Which confirms it's to do with the difference between the Apache KeepAlive time and 60 seconds. I also confirmed that if you et KeepAliveTimeout to an intermediate value (e.g. 20), then you get a 20 second window in which it works and then a 40 second window in which it doesn't. I've also now confirmed that this affects (a recent) MacOS/X Safari as well as iOS Safari and all IE9, 10, 11 and Edge, and double checked that it isn't just in my network (i.e. it is broken for everyone). And I've also confirmed again that this window of time is not a problem if mpm-itk is uninstalled (and AssignUserId commented out). So the problem currently looks like IE and Safari both igniore the keep alive time and just retry anyway, and something in the Apache 2.4 / mpm-itk / SSL combination causes that retry to fail in such a way these browsers either hang or error rather than trying to establish a new connection when that fails. While I don't have a server currently running the Apache 2.2 setup, I do have a backup of /etc and have checked that the old KeepAlive settings were on and 5 as in 2.4, and that was fine. Clearly, it isn't viable to have a 60+ second timeout: it's probably better to turn it off, but neither is satisfactory. Headers pasted below FYI, with Chrome for comparison. They say exactly what I'd expect. *IE11 RESPONSE* Response HTTP/1.1 200 OK Date Fri, 28 Aug 2015 15:42:08 GMT Server Apache/2.4.10 (Debian) Strict-Transport-Security max-age=15768000 Keep-Alive timeout=61, max=100 Connection Keep-Alive Content-Type text/html; charset=UTF-8 Content-Length 195 *IE11 RESPONSE WITH DEFAULT KEEP ALIVE* Key Value Response HTTP/1.1 200 OK Date Fri, 28 Aug 2015 15:48:42 GMT Server Apache/2.4.10 (Debian) Strict-Transport-Security max-age=15768000 Keep-Alive timeout=5, max=100 Connection Keep-Alive Content-Type text/html; charset=UTF-8 Content-Length 195 *IE11 REQUEST* Key Value Request GET / HTTP/1.1 Accept text/html, application/xhtml+xml, */* Accept-Language en-GB User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; EIE10;ENUSWOL; rv:11.0) like Gecko Accept-Encoding gzip, deflate Host www.testapache.com DNT 1 Connection Keep-Alive Cache-Control no-cache *Chrome* Request Method:GET Status Code:200 OK Response Headers Connection:Keep-Alive Content-Encoding:gzip Content-Length:195 Content-Type:text/html; charset=UTF-8 Date:Fri, 28 Aug 2015 15:44:21 GMT Keep-Alive:timeout=61, max=100 Server:Apache/2.4.10 (Debian) Strict-Transport-Security:max-age=15768000 Vary:Accept-Encoding Request Headers Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Encoding:gzip, deflate, sdch Accept-Language:en-GB,en-US;q=0.8,en;q=0.6 Cache-Control:no-cache Connection:keep-alive DNT:1 Host:www.testapache.com Pragma:no-cache Upgrade-Insecure-Requests:1 User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36 On Fri, 28 Aug 2015 at 08:19 wrote: > > Can you try setting KeepAliveTimeout to 61? > > > > Just to be sure - i mean KeepAliveTimeout in Apache. > > > > > > > > > > > > > > > > > > Cit?t David Earl : > > > >> A bit more information... > >> > >> The file upload is a red herring [idiom: misleading evidence], I think. > >> It's actually just the timing. It works if you submit the form within 5 > >> seconds, fails between 5 and 60, and works after 60. > >> > >> It's quite hard to select a file in less than 5 seconds, but that's why > I > >> thought it was working on the second attempt. Actually, it wasn't, it > was > >> just that the file I was choosing was in front of me on the second > attempt > >> so it was quick to select. > >> > >> So, that means the ios and IE11 cases are actually much more similar in > >> their symptoms than I thought. > >> > >> Both 5 seconds and 60 are significant. The default KeepAliveTimeout is > 5, > >> and IE assumes a minimum of 60 I believe. This discrepancy was supposed > to > >> have been dealt with in Apache, which is what the removal of that > >> BrowserMatch directive was all about. But it looks like this isn't the > case > >> when mpm-itk is installed, whether it is down to mpm-itk directly, or a > >> side effect. > >> > >> Who closes the socket after the KeepAliveTimeout? Is it mpm-itk? If > mpm-itk > >> isn't there, who does it? Did Apache put a fix in the other mpm modules > >> which possibly isn't reflected in mpm-itk? > >> > >> Why is it only SSL? Is it possible that it can't determine something > that > >> is browser dependent until it has made the connection, at which time it > is > >> then too late to do anything about it? > >> > >> David > >> > >> > >> > >> David > > > > > > > > > > _______________________________________________ > > mpm-itk mailing list > > mpm-itk at err.no > > http://lists.err.no/mailman/listinfo/mpm-itk > > > > > _______________________________________________ > mpm-itk mailing list > mpm-itk at err.no > http://lists.err.no/mailman/listinfo/mpm-itk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From azurit at pobox.sk Fri Aug 28 20:57:51 2015 From: azurit at pobox.sk (azurit at pobox.sk) Date: Fri, 28 Aug 2015 20:57:51 +0200 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> <20150828084941.Horde.K06azQzFH1T-zcQjFhJcjwu@webmail.inetadmin.eu> <20150828091935.Horde._94a83mBRqccqKG1xjUj1U1@webmail.inetadmin.eu> Message-ID: <20150828205751.Horde.14yvJlSlFi3EnImM1UcT5Uu@webmail.inetadmin.eu> Ok, cool, now can you try to change KeepAlive timeout to 5 seconds in IE ( https://support.microsoft.com/en-us/kb/813827 ) and to 6 seconds in Apache? Cit?t David Earl : > OK, I did that (KeepAliveTimeout 61) originally, and thought it had no > effect, but I was trying so many things, perhaps I forgot to restart Apache > or IE that time, so missed it. (IE caches the value if you just refresh the > page, so you have to restart the browser seemingly). > > Trying it again now, it does indeed make the problem go away. Which > confirms it's to do with the difference between the Apache KeepAlive time > and 60 seconds. I also confirmed that if you et KeepAliveTimeout to an > intermediate value (e.g. 20), then you get a 20 second window in which it > works and then a 40 second window in which it doesn't. > > I've also now confirmed that this affects (a recent) MacOS/X Safari as well > as iOS Safari and all IE9, 10, 11 and Edge, and double checked that it > isn't just in my network (i.e. it is broken for everyone). > > And I've also confirmed again that this window of time is not a problem if > mpm-itk is uninstalled (and AssignUserId commented out). > > So the problem currently looks like IE and Safari both igniore the keep > alive time and just retry anyway, and something in the Apache 2.4 / mpm-itk > / SSL combination causes that retry to fail in such a way these browsers > either hang or error rather than trying to establish a new connection when > that fails. > > While I don't have a server currently running the Apache 2.2 setup, I do > have a backup of /etc and have checked that the old KeepAlive settings were > on and 5 as in 2.4, and that was fine. > > Clearly, it isn't viable to have a 60+ second timeout: it's probably better > to turn it off, but neither is satisfactory. > > Headers pasted below FYI, with Chrome for comparison. They say exactly what > I'd expect. > > *IE11 RESPONSE* > Response HTTP/1.1 200 OK > Date Fri, 28 Aug 2015 15:42:08 GMT > Server Apache/2.4.10 (Debian) > Strict-Transport-Security max-age=15768000 > Keep-Alive timeout=61, max=100 > Connection Keep-Alive > Content-Type text/html; charset=UTF-8 > Content-Length 195 > > *IE11 RESPONSE WITH DEFAULT KEEP ALIVE* > Key Value > Response HTTP/1.1 200 OK > Date Fri, 28 Aug 2015 15:48:42 GMT > Server Apache/2.4.10 (Debian) > Strict-Transport-Security max-age=15768000 > Keep-Alive timeout=5, max=100 > Connection Keep-Alive > Content-Type text/html; charset=UTF-8 > Content-Length 195 > > *IE11 REQUEST* > Key Value > Request GET / HTTP/1.1 > Accept text/html, application/xhtml+xml, */* > Accept-Language en-GB > User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; EIE10;ENUSWOL; > rv:11.0) like Gecko > Accept-Encoding gzip, deflate > Host www.testapache.com > DNT 1 > Connection Keep-Alive > Cache-Control no-cache > > > *Chrome* > Request Method:GET > Status Code:200 OK > > Response Headers > Connection:Keep-Alive > Content-Encoding:gzip > Content-Length:195 > Content-Type:text/html; charset=UTF-8 > Date:Fri, 28 Aug 2015 15:44:21 GMT > Keep-Alive:timeout=61, max=100 > Server:Apache/2.4.10 (Debian) > Strict-Transport-Security:max-age=15768000 > Vary:Accept-Encoding > > Request Headers > Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 > Accept-Encoding:gzip, deflate, sdch > Accept-Language:en-GB,en-US;q=0.8,en;q=0.6 > Cache-Control:no-cache > Connection:keep-alive > DNT:1 > Host:www.testapache.com > Pragma:no-cache > Upgrade-Insecure-Requests:1 > User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, > like Gecko) Chrome/44.0.2403.157 Safari/537.36 > > > > > On Fri, 28 Aug 2015 at 08:19 wrote: > >> > Can you try setting KeepAliveTimeout to 61? >> >> >> >> Just to be sure - i mean KeepAliveTimeout in Apache. >> >> >> >> >> > >> > >> > >> > >> > >> > >> > Cit?t David Earl : >> > >> >> A bit more information... >> >> >> >> The file upload is a red herring [idiom: misleading evidence], I think. >> >> It's actually just the timing. It works if you submit the form within 5 >> >> seconds, fails between 5 and 60, and works after 60. >> >> >> >> It's quite hard to select a file in less than 5 seconds, but that's why >> I >> >> thought it was working on the second attempt. Actually, it wasn't, it >> was >> >> just that the file I was choosing was in front of me on the second >> attempt >> >> so it was quick to select. >> >> >> >> So, that means the ios and IE11 cases are actually much more similar in >> >> their symptoms than I thought. >> >> >> >> Both 5 seconds and 60 are significant. The default KeepAliveTimeout is >> 5, >> >> and IE assumes a minimum of 60 I believe. This discrepancy was supposed >> to >> >> have been dealt with in Apache, which is what the removal of that >> >> BrowserMatch directive was all about. But it looks like this isn't the >> case >> >> when mpm-itk is installed, whether it is down to mpm-itk directly, or a >> >> side effect. >> >> >> >> Who closes the socket after the KeepAliveTimeout? Is it mpm-itk? If >> mpm-itk >> >> isn't there, who does it? Did Apache put a fix in the other mpm modules >> >> which possibly isn't reflected in mpm-itk? >> >> >> >> Why is it only SSL? Is it possible that it can't determine something >> that >> >> is browser dependent until it has made the connection, at which time it >> is >> >> then too late to do anything about it? >> >> >> >> David >> >> >> >> >> >> >> >> David >> > >> > >> > >> > >> > _______________________________________________ >> > mpm-itk mailing list >> > mpm-itk at err.no >> > http://lists.err.no/mailman/listinfo/mpm-itk >> >> >> >> >> _______________________________________________ >> mpm-itk mailing list >> mpm-itk at err.no >> http://lists.err.no/mailman/listinfo/mpm-itk >> From david at frankieandshadow.com Sat Aug 29 12:02:08 2015 From: david at frankieandshadow.com (David Earl) Date: Sat, 29 Aug 2015 10:02:08 +0000 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: <20150828205751.Horde.14yvJlSlFi3EnImM1UcT5Uu@webmail.inetadmin.eu> References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> <20150828084941.Horde.K06azQzFH1T-zcQjFhJcjwu@webmail.inetadmin.eu> <20150828091935.Horde._94a83mBRqccqKG1xjUj1U1@webmail.inetadmin.eu> <20150828205751.Horde.14yvJlSlFi3EnImM1UcT5Uu@webmail.inetadmin.eu> Message-ID: Yes, that's all consistent with the previous tests. Trying various combinations at each end, with mpm-itk installed if the Apache timeout is greater than the IE one it works, but if less it fails in the window of time between them, but works before and after. David On Fri, 28 Aug 2015 at 19:58 wrote: > Ok, cool, now can you try to change KeepAlive timeout to 5 seconds in > IE ( https://support.microsoft.com/en-us/kb/813827 ) and to 6 seconds > in Apache? > > > > > > > Cit?t David Earl : > > > OK, I did that (KeepAliveTimeout 61) originally, and thought it had no > > effect, but I was trying so many things, perhaps I forgot to restart > Apache > > or IE that time, so missed it. (IE caches the value if you just refresh > the > > page, so you have to restart the browser seemingly). > > > > Trying it again now, it does indeed make the problem go away. Which > > confirms it's to do with the difference between the Apache KeepAlive time > > and 60 seconds. I also confirmed that if you et KeepAliveTimeout to an > > intermediate value (e.g. 20), then you get a 20 second window in which it > > works and then a 40 second window in which it doesn't. > > > > I've also now confirmed that this affects (a recent) MacOS/X Safari as > well > > as iOS Safari and all IE9, 10, 11 and Edge, and double checked that it > > isn't just in my network (i.e. it is broken for everyone). > > > > And I've also confirmed again that this window of time is not a problem > if > > mpm-itk is uninstalled (and AssignUserId commented out). > > > > So the problem currently looks like IE and Safari both igniore the keep > > alive time and just retry anyway, and something in the Apache 2.4 / > mpm-itk > > / SSL combination causes that retry to fail in such a way these browsers > > either hang or error rather than trying to establish a new connection > when > > that fails. > > > > While I don't have a server currently running the Apache 2.2 setup, I do > > have a backup of /etc and have checked that the old KeepAlive settings > were > > on and 5 as in 2.4, and that was fine. > > > > Clearly, it isn't viable to have a 60+ second timeout: it's probably > better > > to turn it off, but neither is satisfactory. > > > > Headers pasted below FYI, with Chrome for comparison. They say exactly > what > > I'd expect. > > > > *IE11 RESPONSE* > > Response HTTP/1.1 200 OK > > Date Fri, 28 Aug 2015 15:42:08 GMT > > Server Apache/2.4.10 (Debian) > > Strict-Transport-Security max-age=15768000 > > Keep-Alive timeout=61, max=100 > > Connection Keep-Alive > > Content-Type text/html; charset=UTF-8 > > Content-Length 195 > > > > *IE11 RESPONSE WITH DEFAULT KEEP ALIVE* > > Key Value > > Response HTTP/1.1 200 OK > > Date Fri, 28 Aug 2015 15:48:42 GMT > > Server Apache/2.4.10 (Debian) > > Strict-Transport-Security max-age=15768000 > > Keep-Alive timeout=5, max=100 > > Connection Keep-Alive > > Content-Type text/html; charset=UTF-8 > > Content-Length 195 > > > > *IE11 REQUEST* > > Key Value > > Request GET / HTTP/1.1 > > Accept text/html, application/xhtml+xml, */* > > Accept-Language en-GB > > User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; > EIE10;ENUSWOL; > > rv:11.0) like Gecko > > Accept-Encoding gzip, deflate > > Host www.testapache.com > > DNT 1 > > Connection Keep-Alive > > Cache-Control no-cache > > > > > > *Chrome* > > Request Method:GET > > Status Code:200 OK > > > > Response Headers > > Connection:Keep-Alive > > Content-Encoding:gzip > > Content-Length:195 > > Content-Type:text/html; charset=UTF-8 > > Date:Fri, 28 Aug 2015 15:44:21 GMT > > Keep-Alive:timeout=61, max=100 > > Server:Apache/2.4.10 (Debian) > > Strict-Transport-Security:max-age=15768000 > > Vary:Accept-Encoding > > > > Request Headers > > > Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 > > Accept-Encoding:gzip, deflate, sdch > > Accept-Language:en-GB,en-US;q=0.8,en;q=0.6 > > Cache-Control:no-cache > > Connection:keep-alive > > DNT:1 > > Host:www.testapache.com > > Pragma:no-cache > > Upgrade-Insecure-Requests:1 > > User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, > > like Gecko) Chrome/44.0.2403.157 Safari/537.36 > > > > > > > > > > On Fri, 28 Aug 2015 at 08:19 wrote: > > > >> > Can you try setting KeepAliveTimeout to 61? > >> > >> > >> > >> Just to be sure - i mean KeepAliveTimeout in Apache. > >> > >> > >> > >> > >> > > >> > > >> > > >> > > >> > > >> > > >> > Cit?t David Earl : > >> > > >> >> A bit more information... > >> >> > >> >> The file upload is a red herring [idiom: misleading evidence], I > think. > >> >> It's actually just the timing. It works if you submit the form > within 5 > >> >> seconds, fails between 5 and 60, and works after 60. > >> >> > >> >> It's quite hard to select a file in less than 5 seconds, but that's > why > >> I > >> >> thought it was working on the second attempt. Actually, it wasn't, it > >> was > >> >> just that the file I was choosing was in front of me on the second > >> attempt > >> >> so it was quick to select. > >> >> > >> >> So, that means the ios and IE11 cases are actually much more similar > in > >> >> their symptoms than I thought. > >> >> > >> >> Both 5 seconds and 60 are significant. The default KeepAliveTimeout > is > >> 5, > >> >> and IE assumes a minimum of 60 I believe. This discrepancy was > supposed > >> to > >> >> have been dealt with in Apache, which is what the removal of that > >> >> BrowserMatch directive was all about. But it looks like this isn't > the > >> case > >> >> when mpm-itk is installed, whether it is down to mpm-itk directly, > or a > >> >> side effect. > >> >> > >> >> Who closes the socket after the KeepAliveTimeout? Is it mpm-itk? If > >> mpm-itk > >> >> isn't there, who does it? Did Apache put a fix in the other mpm > modules > >> >> which possibly isn't reflected in mpm-itk? > >> >> > >> >> Why is it only SSL? Is it possible that it can't determine something > >> that > >> >> is browser dependent until it has made the connection, at which time > it > >> is > >> >> then too late to do anything about it? > >> >> > >> >> David > >> >> > >> >> > >> >> > >> >> David > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > mpm-itk mailing list > >> > mpm-itk at err.no > >> > http://lists.err.no/mailman/listinfo/mpm-itk > >> > >> > >> > >> > >> _______________________________________________ > >> mpm-itk mailing list > >> mpm-itk at err.no > >> http://lists.err.no/mailman/listinfo/mpm-itk > >> > > > > > _______________________________________________ > mpm-itk mailing list > mpm-itk at err.no > http://lists.err.no/mailman/listinfo/mpm-itk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From azurit at pobox.sk Sat Aug 29 12:56:10 2015 From: azurit at pobox.sk (azurit at pobox.sk) Date: Sat, 29 Aug 2015 12:56:10 +0200 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> <20150828084941.Horde.K06azQzFH1T-zcQjFhJcjwu@webmail.inetadmin.eu> <20150828091935.Horde._94a83mBRqccqKG1xjUj1U1@webmail.inetadmin.eu> <20150828205751.Horde.14yvJlSlFi3EnImM1UcT5Uu@webmail.inetadmin.eu> Message-ID: <20150829125610.Horde.7AVhzCjKFxRBnwD663QEac6@webmail.inetadmin.eu> Ok, so this means that Apache is closing the connection (after timeout) but IE for some reason thinks that connection is still opened. The error then occurs after IE tries to use closed connection. Currently i can think up two reasons: 1.) Apache is not closing connections correctly. 2.) Something is blocking TCP packets indicating connection close. For (1) i suggest to run TCP network sniffer on client side with and without MPM-ITK installed on server and compare the traffic (mainly after the KeepAlive timeout). For (2) you can try to run TCP network sniffer on both server and client side and see if all packets are getting through to the client (again, mainly after the KeepAlive timeout). Cit?t David Earl : > Yes, that's all consistent with the previous tests. Trying various > combinations at each end, with mpm-itk installed if the Apache timeout is > greater than the IE one it works, but if less it fails in the window of > time between them, but works before and after. > > David > > On Fri, 28 Aug 2015 at 19:58 wrote: > >> Ok, cool, now can you try to change KeepAlive timeout to 5 seconds in >> IE ( https://support.microsoft.com/en-us/kb/813827 ) and to 6 seconds >> in Apache? >> >> >> >> >> >> >> Cit?t David Earl : >> >> > OK, I did that (KeepAliveTimeout 61) originally, and thought it had no >> > effect, but I was trying so many things, perhaps I forgot to restart >> Apache >> > or IE that time, so missed it. (IE caches the value if you just refresh >> the >> > page, so you have to restart the browser seemingly). >> > >> > Trying it again now, it does indeed make the problem go away. Which >> > confirms it's to do with the difference between the Apache KeepAlive time >> > and 60 seconds. I also confirmed that if you et KeepAliveTimeout to an >> > intermediate value (e.g. 20), then you get a 20 second window in which it >> > works and then a 40 second window in which it doesn't. >> > >> > I've also now confirmed that this affects (a recent) MacOS/X Safari as >> well >> > as iOS Safari and all IE9, 10, 11 and Edge, and double checked that it >> > isn't just in my network (i.e. it is broken for everyone). >> > >> > And I've also confirmed again that this window of time is not a problem >> if >> > mpm-itk is uninstalled (and AssignUserId commented out). >> > >> > So the problem currently looks like IE and Safari both igniore the keep >> > alive time and just retry anyway, and something in the Apache 2.4 / >> mpm-itk >> > / SSL combination causes that retry to fail in such a way these browsers >> > either hang or error rather than trying to establish a new connection >> when >> > that fails. >> > >> > While I don't have a server currently running the Apache 2.2 setup, I do >> > have a backup of /etc and have checked that the old KeepAlive settings >> were >> > on and 5 as in 2.4, and that was fine. >> > >> > Clearly, it isn't viable to have a 60+ second timeout: it's probably >> better >> > to turn it off, but neither is satisfactory. >> > >> > Headers pasted below FYI, with Chrome for comparison. They say exactly >> what >> > I'd expect. >> > >> > *IE11 RESPONSE* >> > Response HTTP/1.1 200 OK >> > Date Fri, 28 Aug 2015 15:42:08 GMT >> > Server Apache/2.4.10 (Debian) >> > Strict-Transport-Security max-age=15768000 >> > Keep-Alive timeout=61, max=100 >> > Connection Keep-Alive >> > Content-Type text/html; charset=UTF-8 >> > Content-Length 195 >> > >> > *IE11 RESPONSE WITH DEFAULT KEEP ALIVE* >> > Key Value >> > Response HTTP/1.1 200 OK >> > Date Fri, 28 Aug 2015 15:48:42 GMT >> > Server Apache/2.4.10 (Debian) >> > Strict-Transport-Security max-age=15768000 >> > Keep-Alive timeout=5, max=100 >> > Connection Keep-Alive >> > Content-Type text/html; charset=UTF-8 >> > Content-Length 195 >> > >> > *IE11 REQUEST* >> > Key Value >> > Request GET / HTTP/1.1 >> > Accept text/html, application/xhtml+xml, */* >> > Accept-Language en-GB >> > User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; >> EIE10;ENUSWOL; >> > rv:11.0) like Gecko >> > Accept-Encoding gzip, deflate >> > Host www.testapache.com >> > DNT 1 >> > Connection Keep-Alive >> > Cache-Control no-cache >> > >> > >> > *Chrome* >> > Request Method:GET >> > Status Code:200 OK >> > >> > Response Headers >> > Connection:Keep-Alive >> > Content-Encoding:gzip >> > Content-Length:195 >> > Content-Type:text/html; charset=UTF-8 >> > Date:Fri, 28 Aug 2015 15:44:21 GMT >> > Keep-Alive:timeout=61, max=100 >> > Server:Apache/2.4.10 (Debian) >> > Strict-Transport-Security:max-age=15768000 >> > Vary:Accept-Encoding >> > >> > Request Headers >> > >> Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 >> > Accept-Encoding:gzip, deflate, sdch >> > Accept-Language:en-GB,en-US;q=0.8,en;q=0.6 >> > Cache-Control:no-cache >> > Connection:keep-alive >> > DNT:1 >> > Host:www.testapache.com >> > Pragma:no-cache >> > Upgrade-Insecure-Requests:1 >> > User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, >> > like Gecko) Chrome/44.0.2403.157 Safari/537.36 >> > >> > >> > >> > >> > On Fri, 28 Aug 2015 at 08:19 wrote: >> > >> >> > Can you try setting KeepAliveTimeout to 61? >> >> >> >> >> >> >> >> Just to be sure - i mean KeepAliveTimeout in Apache. >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > Cit?t David Earl : >> >> > >> >> >> A bit more information... >> >> >> >> >> >> The file upload is a red herring [idiom: misleading evidence], I >> think. >> >> >> It's actually just the timing. It works if you submit the form >> within 5 >> >> >> seconds, fails between 5 and 60, and works after 60. >> >> >> >> >> >> It's quite hard to select a file in less than 5 seconds, but that's >> why >> >> I >> >> >> thought it was working on the second attempt. Actually, it wasn't, it >> >> was >> >> >> just that the file I was choosing was in front of me on the second >> >> attempt >> >> >> so it was quick to select. >> >> >> >> >> >> So, that means the ios and IE11 cases are actually much more similar >> in >> >> >> their symptoms than I thought. >> >> >> >> >> >> Both 5 seconds and 60 are significant. The default KeepAliveTimeout >> is >> >> 5, >> >> >> and IE assumes a minimum of 60 I believe. This discrepancy was >> supposed >> >> to >> >> >> have been dealt with in Apache, which is what the removal of that >> >> >> BrowserMatch directive was all about. But it looks like this isn't >> the >> >> case >> >> >> when mpm-itk is installed, whether it is down to mpm-itk directly, >> or a >> >> >> side effect. >> >> >> >> >> >> Who closes the socket after the KeepAliveTimeout? Is it mpm-itk? If >> >> mpm-itk >> >> >> isn't there, who does it? Did Apache put a fix in the other mpm >> modules >> >> >> which possibly isn't reflected in mpm-itk? >> >> >> >> >> >> Why is it only SSL? Is it possible that it can't determine something >> >> that >> >> >> is browser dependent until it has made the connection, at which time >> it >> >> is >> >> >> then too late to do anything about it? >> >> >> >> >> >> David >> >> >> >> >> >> >> >> >> >> >> >> David >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > mpm-itk mailing list >> >> > mpm-itk at err.no >> >> > http://lists.err.no/mailman/listinfo/mpm-itk >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> mpm-itk mailing list >> >> mpm-itk at err.no >> >> http://lists.err.no/mailman/listinfo/mpm-itk >> >> >> >> >> >> >> _______________________________________________ >> mpm-itk mailing list >> mpm-itk at err.no >> http://lists.err.no/mailman/listinfo/mpm-itk >> From azurit at pobox.sk Sat Aug 29 13:00:48 2015 From: azurit at pobox.sk (azurit at pobox.sk) Date: Sat, 29 Aug 2015 13:00:48 +0200 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: <20150829125610.Horde.7AVhzCjKFxRBnwD663QEac6@webmail.inetadmin.eu> References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> <20150828084941.Horde.K06azQzFH1T-zcQjFhJcjwu@webmail.inetadmin.eu> <20150828091935.Horde._94a83mBRqccqKG1xjUj1U1@webmail.inetadmin.eu> <20150828205751.Horde.14yvJlSlFi3EnImM1UcT5Uu@webmail.inetadmin.eu> <20150829125610.Horde.7AVhzCjKFxRBnwD663QEac6@webmail.inetadmin.eu> Message-ID: <20150829130048.Horde.FkfmE2fScBnQGT8EH4X8Wkd@webmail.inetadmin.eu> And one more thing - try to check in which state the connection is after the KeepAliveTimeout in Apache but before the timeout in IE. Unfortunately i don't know how to do it in Windows but i mean some kind of equivalent to netstat command in linux. With this we can tell if the problem is on OS or application level. Cit?t azurit at pobox.sk: > Ok, so this means that Apache is closing the connection (after > timeout) but IE for some reason thinks that connection is still > opened. The error then occurs after IE tries to use closed > connection. Currently i can think up two reasons: > 1.) Apache is not closing connections correctly. > 2.) Something is blocking TCP packets indicating connection close. > > > For (1) i suggest to run TCP network sniffer on client side with and > without MPM-ITK installed on server and compare the traffic (mainly > after the KeepAlive timeout). > For (2) you can try to run TCP network sniffer on both server and > client side and see if all packets are getting through to the client > (again, mainly after the KeepAlive timeout). > > > > > Cit?t David Earl : > >> Yes, that's all consistent with the previous tests. Trying various >> combinations at each end, with mpm-itk installed if the Apache timeout is >> greater than the IE one it works, but if less it fails in the window of >> time between them, but works before and after. >> >> David >> >> On Fri, 28 Aug 2015 at 19:58 wrote: >> >>> Ok, cool, now can you try to change KeepAlive timeout to 5 seconds in >>> IE ( https://support.microsoft.com/en-us/kb/813827 ) and to 6 seconds >>> in Apache? >>> >>> >>> >>> >>> >>> >>> Cit?t David Earl : >>> >>>> OK, I did that (KeepAliveTimeout 61) originally, and thought it had no >>>> effect, but I was trying so many things, perhaps I forgot to restart >>> Apache >>>> or IE that time, so missed it. (IE caches the value if you just refresh >>> the >>>> page, so you have to restart the browser seemingly). >>>> >>>> Trying it again now, it does indeed make the problem go away. Which >>>> confirms it's to do with the difference between the Apache KeepAlive time >>>> and 60 seconds. I also confirmed that if you et KeepAliveTimeout to an >>>> intermediate value (e.g. 20), then you get a 20 second window in which it >>>> works and then a 40 second window in which it doesn't. >>>> >>>> I've also now confirmed that this affects (a recent) MacOS/X Safari as >>> well >>>> as iOS Safari and all IE9, 10, 11 and Edge, and double checked that it >>>> isn't just in my network (i.e. it is broken for everyone). >>>> >>>> And I've also confirmed again that this window of time is not a problem >>> if >>>> mpm-itk is uninstalled (and AssignUserId commented out). >>>> >>>> So the problem currently looks like IE and Safari both igniore the keep >>>> alive time and just retry anyway, and something in the Apache 2.4 / >>> mpm-itk >>>> / SSL combination causes that retry to fail in such a way these browsers >>>> either hang or error rather than trying to establish a new connection >>> when >>>> that fails. >>>> >>>> While I don't have a server currently running the Apache 2.2 setup, I do >>>> have a backup of /etc and have checked that the old KeepAlive settings >>> were >>>> on and 5 as in 2.4, and that was fine. >>>> >>>> Clearly, it isn't viable to have a 60+ second timeout: it's probably >>> better >>>> to turn it off, but neither is satisfactory. >>>> >>>> Headers pasted below FYI, with Chrome for comparison. They say exactly >>> what >>>> I'd expect. >>>> >>>> *IE11 RESPONSE* >>>> Response HTTP/1.1 200 OK >>>> Date Fri, 28 Aug 2015 15:42:08 GMT >>>> Server Apache/2.4.10 (Debian) >>>> Strict-Transport-Security max-age=15768000 >>>> Keep-Alive timeout=61, max=100 >>>> Connection Keep-Alive >>>> Content-Type text/html; charset=UTF-8 >>>> Content-Length 195 >>>> >>>> *IE11 RESPONSE WITH DEFAULT KEEP ALIVE* >>>> Key Value >>>> Response HTTP/1.1 200 OK >>>> Date Fri, 28 Aug 2015 15:48:42 GMT >>>> Server Apache/2.4.10 (Debian) >>>> Strict-Transport-Security max-age=15768000 >>>> Keep-Alive timeout=5, max=100 >>>> Connection Keep-Alive >>>> Content-Type text/html; charset=UTF-8 >>>> Content-Length 195 >>>> >>>> *IE11 REQUEST* >>>> Key Value >>>> Request GET / HTTP/1.1 >>>> Accept text/html, application/xhtml+xml, */* >>>> Accept-Language en-GB >>>> User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; >>> EIE10;ENUSWOL; >>>> rv:11.0) like Gecko >>>> Accept-Encoding gzip, deflate >>>> Host www.testapache.com >>>> DNT 1 >>>> Connection Keep-Alive >>>> Cache-Control no-cache >>>> >>>> >>>> *Chrome* >>>> Request Method:GET >>>> Status Code:200 OK >>>> >>>> Response Headers >>>> Connection:Keep-Alive >>>> Content-Encoding:gzip >>>> Content-Length:195 >>>> Content-Type:text/html; charset=UTF-8 >>>> Date:Fri, 28 Aug 2015 15:44:21 GMT >>>> Keep-Alive:timeout=61, max=100 >>>> Server:Apache/2.4.10 (Debian) >>>> Strict-Transport-Security:max-age=15768000 >>>> Vary:Accept-Encoding >>>> >>>> Request Headers >>>> >>> Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 >>>> Accept-Encoding:gzip, deflate, sdch >>>> Accept-Language:en-GB,en-US;q=0.8,en;q=0.6 >>>> Cache-Control:no-cache >>>> Connection:keep-alive >>>> DNT:1 >>>> Host:www.testapache.com >>>> Pragma:no-cache >>>> Upgrade-Insecure-Requests:1 >>>> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, >>>> like Gecko) Chrome/44.0.2403.157 Safari/537.36 >>>> >>>> >>>> >>>> >>>> On Fri, 28 Aug 2015 at 08:19 wrote: >>>> >>>>> > Can you try setting KeepAliveTimeout to 61? >>>>> >>>>> >>>>> >>>>> Just to be sure - i mean KeepAliveTimeout in Apache. >>>>> >>>>> >>>>> >>>>> >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > Cit?t David Earl : >>>>> > >>>>> >> A bit more information... >>>>> >> >>>>> >> The file upload is a red herring [idiom: misleading evidence], I >>> think. >>>>> >> It's actually just the timing. It works if you submit the form >>> within 5 >>>>> >> seconds, fails between 5 and 60, and works after 60. >>>>> >> >>>>> >> It's quite hard to select a file in less than 5 seconds, but that's >>> why >>>>> I >>>>> >> thought it was working on the second attempt. Actually, it wasn't, it >>>>> was >>>>> >> just that the file I was choosing was in front of me on the second >>>>> attempt >>>>> >> so it was quick to select. >>>>> >> >>>>> >> So, that means the ios and IE11 cases are actually much more similar >>> in >>>>> >> their symptoms than I thought. >>>>> >> >>>>> >> Both 5 seconds and 60 are significant. The default KeepAliveTimeout >>> is >>>>> 5, >>>>> >> and IE assumes a minimum of 60 I believe. This discrepancy was >>> supposed >>>>> to >>>>> >> have been dealt with in Apache, which is what the removal of that >>>>> >> BrowserMatch directive was all about. But it looks like this isn't >>> the >>>>> case >>>>> >> when mpm-itk is installed, whether it is down to mpm-itk directly, >>> or a >>>>> >> side effect. >>>>> >> >>>>> >> Who closes the socket after the KeepAliveTimeout? Is it mpm-itk? If >>>>> mpm-itk >>>>> >> isn't there, who does it? Did Apache put a fix in the other mpm >>> modules >>>>> >> which possibly isn't reflected in mpm-itk? >>>>> >> >>>>> >> Why is it only SSL? Is it possible that it can't determine something >>>>> that >>>>> >> is browser dependent until it has made the connection, at which time >>> it >>>>> is >>>>> >> then too late to do anything about it? >>>>> >> >>>>> >> David >>>>> >> >>>>> >> >>>>> >> >>>>> >> David >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > mpm-itk mailing list >>>>> > mpm-itk at err.no >>>>> > http://lists.err.no/mailman/listinfo/mpm-itk >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpm-itk mailing list >>>>> mpm-itk at err.no >>>>> http://lists.err.no/mailman/listinfo/mpm-itk >>>>> >>> >>> >>> >>> >>> _______________________________________________ >>> mpm-itk mailing list >>> mpm-itk at err.no >>> http://lists.err.no/mailman/listinfo/mpm-itk >>> > > > > > _______________________________________________ > mpm-itk mailing list > mpm-itk at err.no > http://lists.err.no/mailman/listinfo/mpm-itk From informatique.src at gmail.com Sat Aug 29 16:33:03 2015 From: informatique.src at gmail.com (insrc) Date: Sat, 29 Aug 2015 16:33:03 +0200 Subject: [mpm-itk] Problem with AssignUserIDExpr In-Reply-To: <55CBC9CE.7000707@fs.tum.de> References: <55CBC9CE.7000707@fs.tum.de> Message-ID: Hi, I'm encoutering _exactly_ the same issue but on FreeBSD 9.3 and binary package ap24-mod_mpm_itk-2.4.7. The error message is also identical: "AssignUserIDExpr returned '', which is not a valid user name" Apache-mod_mpm_itk-2.2 was working flawlessy using the "AssignUserFromPath" directive until the upgrade. Using the AssigneUserId is not manageable for me as i have to give access 100+ users to their userdir :-/ Here is the config directive i'm using (which is a simple copy/paste from the mpm-itk site): UserDir public_html UserDir disabled root toor daemon operator bin tty kmem games news man sshd smmsp mailnull bind unbound proxy _pflogd _dhcp uucp pop auditdistd www hast nobody @wheel # # Control access to UserDir directories. The following is an example # for a site where these directories are restricted to read-only. # # AssignUserFromPath "^/home/([^/]+)/([^/]+)" $2 $2 RewriteEngine on RewriteRule /~([a-z]+)/ - [E=ITKUID:$1] AssignUserIDExpr %{reqenv:ITKUID} #Require method GET POST OPTIONS #(tech) Require all granted I would really appreciate any help on this issue. Thanks. On Thu, Aug 13, 2015 at 12:33 AM, Kilian R?hner wrote: > Hi everybody, > > on my apache 2.4.10 (Debian) with libapache2-mpm-itk 2.4.7-02-1.1 > installed, I'm trying to get AssignUserIDExpr running in order to run > the user-homes (/~foo) with different permissions (as mentioned on the > website of the module). > > The AssignUserID directive works quite well for me. However, > AssignUserIDExpr is not working as expected. I've broken it down to the > following, not working example: > > SetEnv ITKUID www-bar > AssignUserIDExpr %{reqenv:ITKUID} > > When accessing the webserver, I get in my error.log: > > [mpm_itk:error] [pid 13916] AssignUserIDExpr returned '', which is not a > valid user name > > However, setting AssignUserIDExpr explicitely to a string is working. So > the problem seems to be something with the env-variables. > > Can anybody help me here? > > > By the way, in the process of trying to find the source of the problem, > I found a little bug in mpm_itk.c, line 338. Here, "wanted_username" > should be replaced with "wanted_groupname". > > > Best, Kilian > > _______________________________________________ > mpm-itk mailing list > mpm-itk at err.no > http://lists.err.no/mailman/listinfo/mpm-itk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roehner at fs.tum.de Sat Aug 29 16:44:44 2015 From: roehner at fs.tum.de (=?UTF-8?Q?Kilian_R=c3=b6hner?=) Date: Sat, 29 Aug 2015 16:44:44 +0200 Subject: [mpm-itk] Problem with AssignUserIDExpr In-Reply-To: References: <55CBC9CE.7000707@fs.tum.de> Message-ID: <55E1C55C.9030309@fs.tum.de> Hi, I solved the issue in the meantime. The problem is, that the RewriteRule doesn't get evaluated in time. Don't ask me specifics, but obvioulsy different kind of statements in the config get evaluated at different time (see the comment at [1]). It's also not possible to use SetEnv. However, is is possible to use SetEnvIf. Now, I am using: SetEnvIf Request_URI (.+) ITKUID=default-uid ITKGID=default-gid SetEnvIf Request_URI ^/~([a-z]+)/ ITKUID=$1 SetEnvIf ITKUID ^root$ ITKUID=default-uid AssignUserIDExpr %{reqenv:ITKUID} AssignGroupIDExpr %{reqenv:ITKGID} This can of course be modified by using different regex'es. I actually like this approach better, using this RewriteRule E=... has always looked wrong to me :-) Best, Kilian [1] http://httpd.apache.org/docs/2.4/mod/mod_env.html#setenv Am 29.08.2015 um 16:33 schrieb insrc: > Hi, > I'm encoutering _exactly_ the same issue but on FreeBSD 9.3 and binary > package ap24-mod_mpm_itk-2.4.7. The error message is also identical: > "AssignUserIDExpr returned '', which is not a valid user name" > > Apache-mod_mpm_itk-2.2 was working flawlessy using the "AssignUserFromPath" > directive until the upgrade. > Using the AssigneUserId is not manageable for me as i have to give access > 100+ users to their userdir :-/ > > Here is the config directive i'm using (which is a simple copy/paste from > the mpm-itk site): > > UserDir public_html > > > > UserDir disabled root toor daemon operator bin tty kmem games news man sshd > smmsp mailnull bind unbound proxy _pflogd _dhcp uucp pop auditdistd www > hast nobody @wheel > > # > > # Control access to UserDir directories. The following is an example > > # for a site where these directories are restricted to read-only. > > # > > > > # AssignUserFromPath "^/home/([^/]+)/([^/]+)" $2 $2 > > RewriteEngine on > > RewriteRule /~([a-z]+)/ - [E=ITKUID:$1] > AssignUserIDExpr %{reqenv:ITKUID} > > #Require method GET POST OPTIONS > > #(tech) > > Require all granted > > > > I would really appreciate any help on this issue. > Thanks. > > On Thu, Aug 13, 2015 at 12:33 AM, Kilian R?hner wrote: > >> Hi everybody, >> >> on my apache 2.4.10 (Debian) with libapache2-mpm-itk 2.4.7-02-1.1 >> installed, I'm trying to get AssignUserIDExpr running in order to run >> the user-homes (/~foo) with different permissions (as mentioned on the >> website of the module). >> >> The AssignUserID directive works quite well for me. However, >> AssignUserIDExpr is not working as expected. I've broken it down to the >> following, not working example: >> >> SetEnv ITKUID www-bar >> AssignUserIDExpr %{reqenv:ITKUID} >> >> When accessing the webserver, I get in my error.log: >> >> [mpm_itk:error] [pid 13916] AssignUserIDExpr returned '', which is not a >> valid user name >> >> However, setting AssignUserIDExpr explicitely to a string is working. So >> the problem seems to be something with the env-variables. >> >> Can anybody help me here? >> >> >> By the way, in the process of trying to find the source of the problem, >> I found a little bug in mpm_itk.c, line 338. Here, "wanted_username" >> should be replaced with "wanted_groupname". >> >> >> Best, Kilian >> >> _______________________________________________ >> mpm-itk mailing list >> mpm-itk at err.no >> http://lists.err.no/mailman/listinfo/mpm-itk >> > > > > _______________________________________________ > mpm-itk mailing list > mpm-itk at err.no > http://lists.err.no/mailman/listinfo/mpm-itk > From knut at auvor.no Sun Aug 30 05:01:32 2015 From: knut at auvor.no (Knut Auvor Grythe) Date: Sun, 30 Aug 2015 05:01:32 +0200 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> Message-ID: <20150830030132.GZ8617@pvv.ntnu.no> On Thu, Aug 27, 2015 at 10:33:33PM +0000, David Earl wrote: > Both 5 seconds and 60 are significant. The default KeepAliveTimeout is 5, > and IE assumes a minimum of 60 I believe. This discrepancy was supposed to > have been dealt with in Apache, which is what the removal of that > BrowserMatch directive was all about. But it looks like this isn't the case > when mpm-itk is installed, whether it is down to mpm-itk directly, or a > side effect. Do you know more specifically when or how this was done? Tracking down what change they did to fix it would probably be helpful in determining whether something similar needs to be done in mpm-itk. > Who closes the socket after the KeepAliveTimeout? Is it mpm-itk? If mpm-itk > isn't there, who does it? Did Apache put a fix in the other mpm modules > which possibly isn't reflected in mpm-itk? I don't think mpm-itk does anything related to KeepAliveTimeout. However, mpm-itk does kill the worker (which simulates a connection timeout) in cases of the worker receiving a new request intended for a different UID (i.e. apache has reused the child with a different vhost). There could possibly be some interaction there. To rule out that possibility, perhaps someone could configure it so the same UID is always chosen, and see if the problem persists? > Why is it only SSL? Is it possible that it can't determine something that > is browser dependent until it has made the connection, at which time it is > then too late to do anything about it? As far as I know, mpm-itk doesn't really have any browser-specific logic. I'd be more inclined to believe that the server behaves the same with all browsers, but that the different browsers react to the behavior differently. -- Knut Auvor From knut at auvor.no Sun Aug 30 05:22:21 2015 From: knut at auvor.no (Knut Auvor Grythe) Date: Sun, 30 Aug 2015 05:22:21 +0200 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> <20150828084941.Horde.K06azQzFH1T-zcQjFhJcjwu@webmail.inetadmin.eu> <20150828091935.Horde._94a83mBRqccqKG1xjUj1U1@webmail.inetadmin.eu> Message-ID: <20150830032221.GA8617@pvv.ntnu.no> On Fri, Aug 28, 2015 at 04:22:57PM +0000, David Earl wrote: > So the problem currently looks like IE and Safari both igniore the keep > alive time and just retry anyway, and something in the Apache 2.4 / mpm-itk > / SSL combination causes that retry to fail in such a way these browsers > either hang or error rather than trying to establish a new connection when > that fails. By the way, are you using ssl-unclean-shutdown with IE? This still seems to be required even with modern version of IE. Quoting sites-available/default-ssh.conf in Debian: # SSL Protocol Adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach is that mod_ssl sends the close notify alert but doesn't wait for # the close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # o ssl-unclean-shutdown: # This forces an unclean shutdown when the connection is closed, i.e. no # SSL close notify alert is send or allowed to received. This violates # the SSL/TLS standard but is needed for some brain-dead browsers. Use # this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert. # o ssl-accurate-shutdown: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # practice often causes hanging connections with brain-dead browsers. Use # this only for browsers where you know that their SSL implementation # works correctly. # Notice: Most problems of broken clients are also related to the HTTP # keep-alive facility, so you usually additionally want to disable # keep-alive for those clients, too. Use variable "nokeepalive" for this. # Similarly, one has to force some clients to use HTTP/1.0 to workaround # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this. BrowserMatch "MSIE [2-6]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 # MSIE 7 and newer should be able to use keepalive BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown -- Knut Auvor From knut at auvor.no Sun Aug 30 07:45:18 2015 From: knut at auvor.no (Knut Auvor Grythe) Date: Sun, 30 Aug 2015 07:45:18 +0200 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: <20150830032221.GA8617@pvv.ntnu.no> References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> <20150828084941.Horde.K06azQzFH1T-zcQjFhJcjwu@webmail.inetadmin.eu> <20150828091935.Horde._94a83mBRqccqKG1xjUj1U1@webmail.inetadmin.eu> <20150830032221.GA8617@pvv.ntnu.no> Message-ID: <20150830054518.GB8617@pvv.ntnu.no> On Sun, Aug 30, 2015 at 05:22:21AM +0200, Knut Auvor Grythe wrote: > By the way, are you using ssl-unclean-shutdown with IE? This still seems > to be required even with modern version of IE. I was just able to reproduce your issue, and verified this myself. ssl-unclean-shutdown does not affect this at all, and judging by the code it is in fact not even considered in this case. In this scenario, the connection is closed with the "abortive" shutdown method (which does much the same as unclean) regardless. As mentioned, I was able to reproduce the issue. By setting up a completely default ssl-enabled apache with mpm-itk on debian jessie, the problem was reproducible on Safari version 8.0.7. I was unable to reproduce the issue using Internet Explorer 11.0.9600.17905, though. Perhaps you were using a different version? This is what I did when installing apache on my test server: apt-get install apache2 libapache2-mpm-itk ssl-cert a2dismod mpm_event a2enmod mpm_itk ssl a2ensite default-ssl cat > /var/www/html/foo.html < test
EOF cat > /var/www/html/bar.html < test

Success!

EOF After this, loading https://server-ip/foo.html, waiting 5 seconds and clicking submit made Safari say "Safari can't open the page because the server unexpectedly dropped the connection". -- Knut Auvor From knut at auvor.no Sun Aug 30 08:04:19 2015 From: knut at auvor.no (Knut Auvor Grythe) Date: Sun, 30 Aug 2015 08:04:19 +0200 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: <20150830054518.GB8617@pvv.ntnu.no> References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> <20150828084941.Horde.K06azQzFH1T-zcQjFhJcjwu@webmail.inetadmin.eu> <20150828091935.Horde._94a83mBRqccqKG1xjUj1U1@webmail.inetadmin.eu> <20150830032221.GA8617@pvv.ntnu.no> <20150830054518.GB8617@pvv.ntnu.no> Message-ID: <20150830060419.GC8617@pvv.ntnu.no> On Sun, Aug 30, 2015 at 07:45:18AM +0200, Knut Auvor Grythe wrote: > As mentioned, I was able to reproduce the issue. By setting up a > completely default ssl-enabled apache with mpm-itk on debian jessie, the > problem was reproducible on Safari version 8.0.7. I changed sites-enabled/default-ssl.conf to include LogLevel info ssl:debug and it gave some interesting results. This is the log output when using a plain prefork: [Sat Aug 29 22:43:51.460372 2015] [ssl:info] [pid 13448] [client 10.0.0.126:53615] AH01964: Connection to child 0 established (server obelisk.knuta.net:443) [Sat Aug 29 22:43:51.460612 2015] [ssl:debug] [pid 13448] ssl_engine_kernel.c(1915): [client 10.0.0.126:53615] AH02044: No matching SSL virtual host for servername 10.0.0.182 found (using default/first virtual host) [Sat Aug 29 22:43:51.469229 2015] [ssl:debug] [pid 13448] ssl_engine_kernel.c(1841): [client 10.0.0.126:53615] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES256-SHA384 (256/256 bits) [Sat Aug 29 22:43:51.471082 2015] [ssl:debug] [pid 13448] ssl_engine_kernel.c(243): [client 10.0.0.126:53615] AH02034: Initial (No.1) HTTPS request received for child 0 (server obelisk.knuta.net:443) [Sat Aug 29 22:43:56.473673 2015] [ssl:info] [pid 13448] (70007)The timeout specified has expired: [client 10.0.0.126:53615] AH01991: SSL input filter read failed. [Sat Aug 29 22:43:56.473733 2015] [ssl:debug] [pid 13448] ssl_engine_io.c(1003): [client 10.0.0.126:53615] AH02001: Connection closed to child 0 with standard shutdown (server obelisk.knuta.net:443) This is the log output using mpm-itk: [Sat Aug 29 21:44:06.893103 2015] [ssl:info] [pid 9226] [client 10.0.0.126:53054] AH01964: Connection to child 0 established (server obelisk.knuta.net:443) [Sat Aug 29 21:44:06.893809 2015] [ssl:debug] [pid 9257] ssl_engine_kernel.c(1915): [client 10.0.0.126:53054] AH02044: No matching SSL virtual host for servername 10.0.0.182 found (using default/first virtual host) [Sat Aug 29 21:44:06.901486 2015] [ssl:debug] [pid 9257] ssl_engine_kernel.c(1841): [client 10.0.0.126:53054] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES256-SHA384 (256/256 bits) [Sat Aug 29 21:44:06.903339 2015] [ssl:debug] [pid 9257] ssl_engine_kernel.c(243): [client 10.0.0.126:53054] AH02034: Initial (No.1) HTTPS request received for child 0 (server obelisk.knuta.net:443) [Sat Aug 29 21:44:11.908048 2015] [ssl:info] [pid 9257] (70007)The timeout specified has expired: [client 10.0.0.126:53054] AH01991: SSL input filter read failed. [Sat Aug 29 21:44:16.575984 2015] [ssl:info] [pid 9226] [client 10.0.0.126:53054] AH02008: SSL library error 1 in handshake (server obelisk.knuta.net:443) [Sat Aug 29 21:44:16.576024 2015] [ssl:info] [pid 9226] SSL Library Error: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol -- speaking not SSL to HTTPS port!? [Sat Aug 29 21:44:16.576030 2015] [ssl:info] [pid 9226] [client 10.0.0.126:53054] AH01998: Connection closed to child 0 with abortive shutdown (server obelisk.knuta.net:443) My guess is that that "SSL library error 1 in handshake" and the subsequent "abortive shutdown" has something to do with it. Note that these messages are also logged if I do the same thing using Google Chrome or Firefox, so it should be possible to investigate further without having access to the affected browsers. -- Knut Auvor From azurit at pobox.sk Sun Aug 30 11:14:08 2015 From: azurit at pobox.sk (azurit at pobox.sk) Date: Sun, 30 Aug 2015 11:14:08 +0200 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: <20150830060419.GC8617@pvv.ntnu.no> References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> <20150828084941.Horde.K06azQzFH1T-zcQjFhJcjwu@webmail.inetadmin.eu> <20150828091935.Horde._94a83mBRqccqKG1xjUj1U1@webmail.inetadmin.eu> <20150830032221.GA8617@pvv.ntnu.no> <20150830054518.GB8617@pvv.ntnu.no> <20150830060419.GC8617@pvv.ntnu.no> Message-ID: <20150830111408.Horde.GC5Ocky-4-g3TtDOxPkJ902@webmail.inetadmin.eu> > Note that these messages are also logged if I do the same thing using > Google Chrome or Firefox, so it should be possible to investigate > further without having access to the affected browsers. Other browsers are probably able to handle such errors better. Can you sniff the traffic so we can see what data was received by Apache which causes this error? By the way, looking on your logs, there are 3 different PIDs: - 9226, this is probably Apache child - 9257, this is probably process spawned by Apache child to handle the request - 9226, what is this? it's the one printing errors Or the first one is the main apache process? Can you check? From david at frankieandshadow.com Sun Aug 30 14:07:47 2015 From: david at frankieandshadow.com (David Earl) Date: Sun, 30 Aug 2015 12:07:47 +0000 Subject: [mpm-itk] mpm-itk, SSL, Apache 2.4, KeepAlive and IE11 / iOS Safari In-Reply-To: <20150830060419.GC8617@pvv.ntnu.no> References: <20150827170634.GW8617@pvv.ntnu.no> <20150827202116.Horde.AcDhmOfgFoNViF2WMbSsWla@webmail.inetadmin.eu> <20150828084941.Horde.K06azQzFH1T-zcQjFhJcjwu@webmail.inetadmin.eu> <20150828091935.Horde._94a83mBRqccqKG1xjUj1U1@webmail.inetadmin.eu> <20150830032221.GA8617@pvv.ntnu.no> <20150830054518.GB8617@pvv.ntnu.no> <20150830060419.GC8617@pvv.ntnu.no> Message-ID: Ah, progress, thank you. I'll try this on IE11 when I get a moment - it's odd you aren't seeing it there given 9,11 and Edge all seem to have the problem. Peraps your IE timeout isn't the default? Re ss-unclean-shutdown, Apache seems to have removed this from the default SSL config - it was there in ssl.conf in 2.2 but not in 2.4. But as you say, this doesn't seem to be relevant, and certainly I'd found it not to make any difference. I will also see if I can get a vanilla Debian 7 Wheezy Apache 2.2 + mpm-itk install to compare with, but probably not today. David On Sun, 30 Aug 2015 at 07:04 Knut Auvor Grythe wrote: > On Sun, Aug 30, 2015 at 07:45:18AM +0200, Knut Auvor Grythe wrote: > > As mentioned, I was able to reproduce the issue. By setting up a > > completely default ssl-enabled apache with mpm-itk on debian jessie, the > > problem was reproducible on Safari version 8.0.7. > > I changed sites-enabled/default-ssl.conf to include > LogLevel info ssl:debug > and it gave some interesting results. > > This is the log output when using a plain prefork: > > [Sat Aug 29 22:43:51.460372 2015] [ssl:info] [pid 13448] [client > 10.0.0.126:53615] AH01964: Connection to child 0 established (server > obelisk.knuta.net:443) > [Sat Aug 29 22:43:51.460612 2015] [ssl:debug] [pid 13448] > ssl_engine_kernel.c(1915): [client 10.0.0.126:53615] AH02044: No matching > SSL virtual host for servername 10.0.0.182 found (using default/first > virtual host) > [Sat Aug 29 22:43:51.469229 2015] [ssl:debug] [pid 13448] > ssl_engine_kernel.c(1841): [client 10.0.0.126:53615] AH02041: Protocol: > TLSv1.2, Cipher: ECDHE-RSA-AES256-SHA384 (256/256 bits) > [Sat Aug 29 22:43:51.471082 2015] [ssl:debug] [pid 13448] > ssl_engine_kernel.c(243): [client 10.0.0.126:53615] AH02034: Initial > (No.1) HTTPS request received for child 0 (server obelisk.knuta.net:443) > [Sat Aug 29 22:43:56.473673 2015] [ssl:info] [pid 13448] (70007)The > timeout specified has expired: [client 10.0.0.126:53615] AH01991: SSL > input filter read failed. > [Sat Aug 29 22:43:56.473733 2015] [ssl:debug] [pid 13448] > ssl_engine_io.c(1003): [client 10.0.0.126:53615] AH02001: Connection > closed to child 0 with standard shutdown (server obelisk.knuta.net:443) > > This is the log output using mpm-itk: > > [Sat Aug 29 21:44:06.893103 2015] [ssl:info] [pid 9226] [client > 10.0.0.126:53054] AH01964: Connection to child 0 established (server > obelisk.knuta.net:443) > [Sat Aug 29 21:44:06.893809 2015] [ssl:debug] [pid 9257] > ssl_engine_kernel.c(1915): [client 10.0.0.126:53054] AH02044: No matching > SSL virtual host for servername 10.0.0.182 found (using default/first > virtual host) > [Sat Aug 29 21:44:06.901486 2015] [ssl:debug] [pid 9257] > ssl_engine_kernel.c(1841): [client 10.0.0.126:53054] AH02041: Protocol: > TLSv1.2, Cipher: ECDHE-RSA-AES256-SHA384 (256/256 bits) > [Sat Aug 29 21:44:06.903339 2015] [ssl:debug] [pid 9257] > ssl_engine_kernel.c(243): [client 10.0.0.126:53054] AH02034: Initial > (No.1) HTTPS request received for child 0 (server obelisk.knuta.net:443) > [Sat Aug 29 21:44:11.908048 2015] [ssl:info] [pid 9257] (70007)The timeout > specified has expired: [client 10.0.0.126:53054] AH01991: SSL input > filter read failed. > [Sat Aug 29 21:44:16.575984 2015] [ssl:info] [pid 9226] [client > 10.0.0.126:53054] AH02008: SSL library error 1 in handshake (server > obelisk.knuta.net:443) > [Sat Aug 29 21:44:16.576024 2015] [ssl:info] [pid 9226] SSL Library Error: > error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol -- > speaking not SSL to HTTPS port!? > [Sat Aug 29 21:44:16.576030 2015] [ssl:info] [pid 9226] [client > 10.0.0.126:53054] AH01998: Connection closed to child 0 with abortive > shutdown (server obelisk.knuta.net:443) > > My guess is that that "SSL library error 1 in handshake" and the > subsequent "abortive shutdown" has something to do with it. > > Note that these messages are also logged if I do the same thing using > Google Chrome or Firefox, so it should be possible to investigate > further without having access to the affected browsers. > > -- > Knut Auvor > > _______________________________________________ > mpm-itk mailing list > mpm-itk at err.no > http://lists.err.no/mailman/listinfo/mpm-itk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From informatique.src at gmail.com Mon Aug 31 08:20:41 2015 From: informatique.src at gmail.com (insrc) Date: Mon, 31 Aug 2015 08:20:41 +0200 Subject: [mpm-itk] Problem with AssignUserIDExpr In-Reply-To: <55E1C55C.9030309@fs.tum.de> References: <55CBC9CE.7000707@fs.tum.de> <55E1C55C.9030309@fs.tum.de> Message-ID: On Sat, Aug 29, 2015 at 4:44 PM, Kilian R?hner wrote: > Hi, > > Hi Kilian, > I solved the issue in the meantime. > > The problem is, that the RewriteRule doesn't get evaluated in time. > Don't ask me specifics, but obvioulsy different kind of statements in > the config get evaluated at different time (see the comment at [1]). > It's also not possible to use SetEnv. > > However, is is possible to use SetEnvIf. Now, I am using: > > SetEnvIf Request_URI (.+) ITKUID=default-uid ITKGID=default-gid > SetEnvIf Request_URI ^/~([a-z]+)/ ITKUID=$1 > SetEnvIf ITKUID ^root$ ITKUID=default-uid > AssignUserIDExpr %{reqenv:ITKUID} > AssignGroupIDExpr %{reqenv:ITKGID} > > Thanks a lot ! Unfortunately, I've copied the configuration exceprt above but still facing the same issue. I must be doing something wrong but really don't know how to debug this issue :-/ Anyway, i'll try to do some more test on a fresh FreeBSD 9.3 installation Again, thanks for your helpfull answer ! Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From knut at auvor.no Mon Aug 31 09:21:18 2015 From: knut at auvor.no (Knut Auvor Grythe) Date: Mon, 31 Aug 2015 09:21:18 +0200 Subject: [mpm-itk] Problem with AssignUserIDExpr In-Reply-To: References: <55CBC9CE.7000707@fs.tum.de> <55E1C55C.9030309@fs.tum.de> Message-ID: <20150831072118.GF8617@pvv.ntnu.no> On Mon, Aug 31, 2015 at 08:20:41AM +0200, insrc wrote: >> However, is is possible to use SetEnvIf. Now, I am using: >> >> SetEnvIf Request_URI (.+) ITKUID=default-uid ITKGID=default-gid >> SetEnvIf Request_URI ^/~([a-z]+)/ ITKUID=$1 This does a case-sensitive match on only lowercase characters, no numbers. Just to verify, I presume your test user does not have a number or uppercase character in the name? >> SetEnvIf ITKUID ^root$ ITKUID=default-uid >> AssignUserIDExpr %{reqenv:ITKUID} >> AssignGroupIDExpr %{reqenv:ITKGID} > > Unfortunately, I've copied the configuration exceprt above but still facing > the same issue. I must be doing something wrong but really don't know how > to debug this issue :-/ You might be able to increase the loglevel of mod_setenvif. I believe the setting should be something like this within your virtualhost configuration: LogLevel warn setenvif:debug This would enable debug logging of mod_setenvif, and warn logging of anything else. If you go back to the mod_rewrite solution discussed earlier, that has similar constructs for logging: http://httpd.apache.org/docs/current/mod/mod_rewrite.html#logging -- Knut Auvor From knut at auvor.no Mon Aug 31 11:43:36 2015 From: knut at auvor.no (Knut Auvor Grythe) Date: Mon, 31 Aug 2015 11:43:36 +0200 Subject: [mpm-itk] MaxClientsVhost reached In-Reply-To: <20150806102809.GA20860@sesse.net> References: <55C24092.7090203@altlinux.ru> <20150805191325.GA5084@sesse.net> <55C26421.8090202@altlinux.ru> <20150805193705.GA13105@sesse.net> <55C3349E.4070506@altlinux.ru> <20150806102809.GA20860@sesse.net> Message-ID: <20150831094336.GG8617@pvv.ntnu.no> On Thu, Aug 06, 2015 at 12:28:09PM +0200, Steinar H. Gunderson wrote: >> It show more connections to site. but it ghost connections. tcpdump and >> some other tool not show active connections from this source. > > If Apache thinks there are connections in the scoreboard where there's not, > it's an Apache bug and there's nothing mpm-itk can do. Could it be that the count gets tripped up whenever we do exit(1) in in itk_fork_process(), though? Are there a lot of "child died with signal", "child exited with non-zero exit status" or "waitpid() failed" in the logs? They are logged in the error loglevel. If not, I agree with Steinar that it is most likely an Apache bug and not mpm-itk. -- Knut Auvor