From allen44@example.org Tue Sep 01 06:43:30 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 65606 invoked from network); 1 Sep 2009 06:43:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 06:43:30 -0000 Received: (qmail 41194 invoked by uid 500); 1 Sep 2009 06:43:29 -0000 Delivered-To: allen44@example.org Received: (qmail 41114 invoked by uid 500); 1 Sep 2009 06:43:29 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 41105 invoked by uid 99); 1 Sep 2009 06:43:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 06:43:29 +0000 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO eru.sfritsch.de) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 06:43:20 +0000 Received: from k.lan ([83.161.120.155] helo=k.localnet) by eru.sfritsch.de with esmtp (Exim 4.63) (envelope-from <allen44@example.org>) id 1MiN51-00007b-0S for allen44@example.org; Tue, 01 Sep 2009 08:42:59 +0200 From: Stefan Fritsch <allen44@example.org> To: allen44@example.org Subject: Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach) Date: Tue, 1 Sep 2009 08:42:56 +0200 User-Agent: KMail/1.12.0 (Linux/2.6.30-1-686; KDE/4.3.0; i686; ; ) References: <allen44@example.org> <allen44@example.org> In-Reply-To: <allen44@example.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <allen44@example.org> X-Virus-Checked: Checked by ClamAV on apache.org On Tuesday 01 September 2009, Nick Kew wrote: > How does it relate to the Timeout directive? The Timeout directive sets the maximum time between two packets. mod_requtimeout will set the socket timeout to the minumum of {Timeout, time left for the current request}. You can set RequestTimeout to much lower values than Timeout and it still works as expected. > > One comment: you're returning APR_EGENERAL if there's no config. > I'd strongly suggest you always do-nothing if not configured. > Or if not-configured is a can't-happen event, catch it with > an ap_assert. Not-configured should not happen and would be a bug, I will change it to ap_assert. > > - Obviously the body read timeout is only useful for sites that > > do not allow file uploads. But an extension to a minimum body > > transfer rate would probably be possible. Also, it would be > > possible to make the body read timeout configurable by direcory, > > which may be useful if file uploads are only allowed by > > authorized users. > > The body part probably overlaps with what existing modules like > mod_evasive and the bandwidth-management modules do. Have you > looked at them? I haven't looked very allen44@example.org. But from the descriptions it looked like they defend against too much traffic/requests. I try to defend against connections with very little traffic. And unless they fiddle with the socket timeout too, they are limited by the value of the Timeout directive. Once apache is in a blocking read, the modules can't do anything until the timeout expires. When Timeout is set to a large value like 300s (e.g. because of mod_cgi), mod_reqtimeout can still limit the maximum time for reading the body to a much lower value (like 15s for sites that have only forms and no file uploads). I also start counting the bodytimeout only when there is the first read for the body. That way the time needed by apache to process the request is not included. > > - Apache should respond with HTTP_REQUEST_TIME_OUT and not > > HTTP_BAD_REQUEST when there is a timeout reading the request. > > In the slowloris case, it needs to time out before there's any such > thing as an HTTP request, so it won't be sending an HTTP response. > But I guess you're talking about the body timeout? No, about the request. When apache has received at least one line of the request, it currently responds with HTTP_BAD_REQUEST when there is a timeout before the complete request was read. In this case HTTP_REQUEST_TIME_OUT is more appropriate. It means "the client did not produce a request within the time that the server was prepared to wait". From allen44@example.org Tue Sep 01 09:58:55 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 12728 invoked from network); 1 Sep 2009 09:58:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 09:58:55 -0000 Received: (qmail 65234 invoked by uid 500); 1 Sep 2009 09:58:53 -0000 Delivered-To: allen44@example.org Received: (qmail 65173 invoked by uid 500); 1 Sep 2009 09:58:53 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 65164 invoked by uid 99); 1 Sep 2009 09:58:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 09:58:53 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of allen44@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-iw0-f181.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 09:58:44 +0000 Received: by iwn11 with SMTP id 11so2071260iwn.10 for <allen44@example.org>; Tue, 01 Sep 2009 02:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=5e3PJ8/5F1VOkfCC3Gjw5t/ZfqkwfnFldruaw6UA7os=; b=KyfAGZ0LS5094/YNvi31a1R+sjcF1wzRsy21iNMvOS4z4oV2wiQgcb+c49CyqbXSrn Xp76yoos9ZNvV1iV6u7nCOn5B3NfCd9LnKFuiQ7cmaiyUZQLWWnE4kybUrk5Au2NpfyL FeuGsDpEuHASuH2+kaMbyl3X/oZa8OpplB0fk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=pW5zfEjG1/NJEC0wxjEyyDC0OwtpPxKeIiEalnPdMAOX99brgF2CzZF+FTmJWzQ6K5 lY14d2O44aOLmc2fKjfA+G+NzfzU/HlGx2uiIbm5dt6xAMitGS27oFt3nIMN31meKXYr gVjE65UVZB9F1BN3Yn4WODGlMUVdgM0TVH1dI= MIME-Version: 1.0 Received: by 83.161.120.155 with SMTP id e11mr7840474ibl.11.1251799103561; Tue, 01 Sep 2009 02:58:23 -0700 (PDT) Date: Tue, 1 Sep 2009 15:28:23 +0530 Message-ID: <allen44@example.org> Subject: slowloris DoS attack-How to check time taken by server for reading a request From: nikhil kohli <allen44@example.org> To: allen44@example.org Content-Type: multipart/alternative; boundary=000e0cd6aa06e5e03d0472813078 X-Virus-Checked: Checked by ClamAV on apache.org --000e0cd6aa06e5e03d0472813078 Content-Type: text/plain; charset=ISO-8859-1 Hello Everyone, This is regarding the slowloris issue. I'm trying to mitigate this issue using iptables by restricting the no. of connection to a certain limit. Also i see the new experimental module mod_noloris.c having similar approach to mitigate slowloris attack. I have few questions regarding this approach. 1. Can we mitigate the issue using iptables only? 2. Even mod_noloris.c is vulnerable to slowloris attack, will there be a change in approach for solving this in future? 3. Is there a way to delay the process of creating connection until whole header is received? 4. How to check time taken by server for reading the request? Also, may i know if apache team acknowledge slowloris as issue or not? Thanks in advance. Thanks and Regards, Nikhil Kohli --000e0cd6aa06e5e03d0472813078 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Hello Everyone,</div> <div><br>This is regarding the slowloris issue. I&#39;m trying to mitigate = this issue using iptables by restricting the no. of connection to a certain= limit. Also i see the new experimental module mod_noloris.c having similar= approach to mitigate slowloris attack. I have few questions regarding this= =A0 approach.<br> </div> <div>1. Can we mitigate the issue using iptables only?<br>2. Even mod_nolor= is.c is vulnerable to slowloris attack, will there be a change in approach = for solving this in future?<br>3. Is there a way to delay the process of cr= eating connection until whole header is received?<br> 4. How to check time taken by server for reading the request? <br></div> <div>Also, may i know if apache team acknowledge slowloris as issue or not?= <br>Thanks in advance.<br></div> <div>Thanks and Regards,<br>Nikhil Kohli</div> --000e0cd6aa06e5e03d0472813078-- From allen44@example.org Tue Sep 01 11:39:07 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 38008 invoked from network); 1 Sep 2009 11:39:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 11:39:07 -0000 Received: (qmail 76145 invoked by uid 500); 1 Sep 2009 11:39:06 -0000 Delivered-To: allen44@example.org Received: (qmail 76063 invoked by uid 500); 1 Sep 2009 11:39:05 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 76051 invoked by uid 99); 1 Sep 2009 11:39:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 11:39:05 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of allen44@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-bw0-f208.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 11:38:56 +0000 Received: by bwz4 with SMTP id 4so34301bwz.24 for <allen44@example.org>; Tue, 01 Sep 2009 04:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=yyan+0XLE2o2ypZ6Hw+AX1nnCoiIdWvcLXtzrmYtpcY=; b=iTJumAkKP+tK5asd43e5fjXu7FQXzB9c8DoOPkLD09JNnxpPVOisge7iw2HkxyKKsO tvcdg/dyK6pK//HcKqFaZGkD4AxRTNFuSF8UKPJdjcqhGA/ui+lgb7Ow9XFi1GZf5fZ3 U9VWJd6DTm+JcqqcWzgE4FmpYwlZRbLNfCQF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=kK4q2OiVKqJY5McSIqO4GoQdosve1eY9rhaqviZMw5RGV9y/+mz8yAhQeWI6O87iao Gs4pCurF/rxt+hJSwS7T+J5TSCovscZySFW3RQ61R5NSzosslwr5D3fz94S1/wnkvrMH /4CleKvptVPonqwsDhOpSCxD01kbnlK40Nry4= MIME-Version: 1.0 Received: by 83.161.120.155 with SMTP id s18mr2420079fau.71.1251805115874; Tue, 01 Sep 2009 04:38:35 -0700 (PDT) In-Reply-To: <allen44@example.org> References: <allen44@example.org> Date: Tue, 1 Sep 2009 07:38:35 -0400 Message-ID: <allen44@example.org> Subject: Re: slowloris DoS attack-How to check time taken by server for reading a request From: Eric Covener <allen44@example.org> To: allen44@example.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Sep 1, 2009 at 5:58 AM, nikhil kohli<allen44@example.org> wrote: > 1. Can we mitigate the issue using iptables only? That seems to be the conventional wisdom. > 2. Even mod_noloris.c is vulnerable to slowloris attack, will there be a > change in approach for solving this in future? People seem to be working on it from a few angles, and there are already multiple modules that address it -- I wouldn't call this one authoritative or final in any way. > 3. Is there a way to delay the process of creating connection until whole > header is received? I don't think so, can you elaborate on what you mean by creating a connection? > 4. How to check time taken by server for reading the request? The core notes the time when the request line is read, but not when all the headers are done. Modules are can easily note these times though by springing to life in the right hook. These types of questions are better posed on allen44@example.org > Also, may i know if apache team acknowledge slowloris as issue or not? Can't speak for anyone else, but it seems to be acknowledged mostly as a scalability/optimization issue which has already been on the radar (and only as a pressing issue at the firewall level) -- Eric Covener allen44@example.org From allen44@example.org Tue Sep 01 14:27:28 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 93985 invoked from network); 1 Sep 2009 14:27:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 14:27:28 -0000 Received: (qmail 13571 invoked by uid 500); 1 Sep 2009 14:27:27 -0000 Delivered-To: allen44@example.org Received: (qmail 13485 invoked by uid 500); 1 Sep 2009 14:27:27 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 13476 invoked by uid 99); 1 Sep 2009 14:27:27 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 14:27:27 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of allen44@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail.gmx.net) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 01 Sep 2009 14:27:16 +0000 Received: (qmail invoked by alias); 01 Sep 2009 14:26:55 -0000 Received: from unknown (EHLO opi.home) [83.161.120.155] by mail.gmx.net (mp024) with SMTP; 01 Sep 2009 16:26:55 +0200 X-Authenticated: #1700068 X-Provags-ID: V01U2FsdGVkX1/A0HlqGgjAYOkn68PSpzbF4PApf8Ns/GDhE9jKHi KXaVfvuZ8LNYbs From: Torsten Foertsch <allen44@example.org> To: allen44@example.org Subject: Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach) Date: Tue, 1 Sep 2009 16:26:52 +0200 User-Agent: KMail/1.9.10 References: <allen44@example.org> In-Reply-To: <allen44@example.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <allen44@example.org> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 X-Virus-Checked: Checked by ClamAV on apache.org On Tue 01 Sep 2009, Stefan Fritsch wrote: > http://www.sfritsch.de/mod_reqtimeout/mod_reqtimeout.c > > Any comments are welcome. Just a few thoughts: =2D You use GLOBAL_ONLY in ap_check_cmd_context. That means the directive=20 must not appear in vhost context. AFAIK, conn->base_server reflects the=20 vhost in a pre connection hook if it is IP-based. So, why don't you=20 allow for RequestTimeout to be valid in ip-based vhost context? That=20 way the protocol problem is solved, isn't it? =2D Wouldn't RequestTimeout better be named RequestHeaderTimeout or=20 ReadRequestHeaderTimeout? RequestTimeout is a bit missleading (IMHO).=20 My first thought was: That thing limits the whole transaction. =2D You mentioned a minimum body transfer rate instead of a simple=20 timeout. If the default values for LimitRequestFields,=20 LimitRequestFieldSize and LimitRequestLine are added up I get a max.=20 request header size of 101*8190 bytes. This may take some time to=20 transmit while still valid. So, perhaps a transfer rate limit for the=20 header is a good option, as well. Perhaps having both a timeout and a=20 rate limit would be good. Just my 0.02=E2=82=AC. Torsten =2D-=20 Need professional mod_perl support? Just hire me: allen44@example.org From allen44@example.org Tue Sep 01 18:48:31 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 85068 invoked from network); 1 Sep 2009 18:48:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 18:48:31 -0000 Received: (qmail 11850 invoked by uid 500); 1 Sep 2009 18:48:30 -0000 Delivered-To: allen44@example.org Received: (qmail 11775 invoked by uid 500); 1 Sep 2009 18:48:30 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 11766 invoked by uid 99); 1 Sep 2009 18:48:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 18:48:30 +0000 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [83.161.120.155] (HELO eru.sfritsch.de) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 18:48:21 +0000 Received: from k.lan ([83.161.120.155] helo=k.localnet) by eru.sfritsch.de with esmtp (Exim 4.63) (envelope-from <allen44@example.org>) id 1MiYOe-0005FN-Mv for allen44@example.org; Tue, 01 Sep 2009 20:48:00 +0200 From: Stefan Fritsch <allen44@example.org> To: allen44@example.org Subject: Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach) Date: Tue, 1 Sep 2009 20:47:56 +0200 User-Agent: KMail/1.12.0 (Linux/2.6.30-1-686; KDE/4.3.0; i686; ; ) References: <allen44@example.org> <allen44@example.org> In-Reply-To: <allen44@example.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <allen44@example.org> X-Virus-Checked: Checked by ClamAV on apache.org On Tuesday 01 September 2009, Torsten Foertsch wrote: > Just a few thoughts: > > - You use GLOBAL_ONLY in ap_check_cmd_context. That means the > directive must not appear in vhost context. AFAIK, > conn->base_server reflects the vhost in a pre connection hook if it > is IP-based. So, why don't you allow for RequestTimeout to be valid > in ip-based vhost context? Basically because I didn't get around to write the merge function yet. But it's on my todo list. > That way the protocol problem is solved, > isn't it? That's true. It's probably not necessary to detect non-http virtual hosts automatically. Just let the admin configure it. > - Wouldn't RequestTimeout better be named RequestHeaderTimeout or > ReadRequestHeaderTimeout? RequestTimeout is a bit missleading > (IMHO). My first thought was: That thing limits the whole > transaction. Maybe. I will think about this. > > - You mentioned a minimum body transfer rate instead of a simple > timeout. If the default values for LimitRequestFields, > LimitRequestFieldSize and LimitRequestLine are added up I get a > max. request header size of 101*8190 bytes. This may take some time > to transmit while still valid. So, perhaps a transfer rate limit > for the header is a good option, as well. Perhaps having both a > timeout and a rate limit would be good. A more realistic estimate for the maximum for a valid request is 10*8190 + 91*100, i.e. there are normally only very vew long lines. But if the transfer rate function is added for the body, it's easy to add it for the headers, too. From allen44@example.org Tue Sep 01 19:10:20 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 91413 invoked from network); 1 Sep 2009 19:10:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 19:10:20 -0000 Received: (qmail 48229 invoked by uid 500); 1 Sep 2009 19:10:19 -0000 Delivered-To: allen44@example.org Received: (qmail 48139 invoked by uid 500); 1 Sep 2009 19:10:19 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 48130 invoked by uid 99); 1 Sep 2009 19:10:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 19:10:19 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO minotaur.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 01 Sep 2009 19:10:10 +0000 Received: (qmail 91363 invoked by uid 2161); 1 Sep 2009 19:09:50 -0000 Received: from [83.161.120.155] (euler.heimnetz.de [83.161.120.155]) by cerberus.heimnetz.de (Postfix on SuSE Linux 7.0 (i386)) with ESMTP id 69C121721C for <allen44@example.org>; Tue, 1 Sep 2009 21:09:37 +0200 (CEST) Message-ID: <allen44@example.org> Date: Tue, 01 Sep 2009 21:09:50 +0200 From: Ruediger Pluem <allen44@example.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:83.161.120.155) Gecko/20090606 SeaMonkey/1.1.17 MIME-Version: 1.0 To: allen44@example.org Subject: Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach) References: <allen44@example.org> <allen44@example.org> In-Reply-To: <allen44@example.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org On 09/01/2009 04:26 PM, Torsten Foertsch wrote: > On Tue 01 Sep 2009, Stefan Fritsch wrote: >> http://www.sfritsch.de/mod_reqtimeout/mod_reqtimeout.c >> >> Any comments are welcome. > > Just a few thoughts: > > - You use GLOBAL_ONLY in ap_check_cmd_context. That means the directive > must not appear in vhost context. AFAIK, conn->base_server reflects the > vhost in a pre connection hook if it is IP-based. So, why don't you > allow for RequestTimeout to be valid in ip-based vhost context? That > way the protocol problem is solved, isn't it? > > - Wouldn't RequestTimeout better be named RequestHeaderTimeout or > ReadRequestHeaderTimeout? RequestTimeout is a bit missleading (IMHO). > My first thought was: That thing limits the whole transaction. Nice module. +1 to the comments above. Regards Rüdiger From allen44@example.org Tue Sep 01 19:13:23 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 92285 invoked from network); 1 Sep 2009 19:13:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 19:13:23 -0000 Received: (qmail 51817 invoked by uid 500); 1 Sep 2009 19:13:22 -0000 Delivered-To: allen44@example.org Received: (qmail 51746 invoked by uid 500); 1 Sep 2009 19:13:22 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 51737 invoked by uid 99); 1 Sep 2009 19:13:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 19:13:22 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO minotaur.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 01 Sep 2009 19:13:20 +0000 Received: (qmail 92029 invoked by uid 2161); 1 Sep 2009 19:13:00 -0000 Received: from [83.161.120.155] (euler.heimnetz.de [83.161.120.155]) by cerberus.heimnetz.de (Postfix on SuSE Linux 7.0 (i386)) with ESMTP id 348B41721C for <allen44@example.org>; Tue, 1 Sep 2009 21:12:50 +0200 (CEST) Message-ID: <allen44@example.org> Date: Tue, 01 Sep 2009 21:13:03 +0200 From: Ruediger Pluem <allen44@example.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:83.161.120.155) Gecko/20090606 SeaMonkey/1.1.17 MIME-Version: 1.0 To: allen44@example.org Subject: Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach) References: <allen44@example.org> <allen44@example.org> <allen44@example.org> In-Reply-To: <allen44@example.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org On 09/01/2009 08:42 AM, Stefan Fritsch wrote: > On Tuesday 01 September 2009, Nick Kew wrote: > >>> - Apache should respond with HTTP_REQUEST_TIME_OUT and not >>> HTTP_BAD_REQUEST when there is a timeout reading the request. >> In the slowloris case, it needs to time out before there's any such >> thing as an HTTP request, so it won't be sending an HTTP response. >> But I guess you're talking about the body timeout? > > No, about the request. When apache has received at least one line of > the request, it currently responds with HTTP_BAD_REQUEST when there is > a timeout before the complete request was read. In this case > HTTP_REQUEST_TIME_OUT is more appropriate. It means "the client did > not produce a request within the time that the server was prepared to > wait". Is this just regarding better logging on the server side? Otherwise I wouldn't care too much what we sent to an attacker. Regards Rüdiger From allen44@example.org Tue Sep 01 19:39:37 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 98773 invoked from network); 1 Sep 2009 19:39:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 19:39:37 -0000 Received: (qmail 77851 invoked by uid 500); 1 Sep 2009 19:39:36 -0000 Delivered-To: allen44@example.org Received: (qmail 77762 invoked by uid 500); 1 Sep 2009 19:39:36 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 77753 invoked by uid 99); 1 Sep 2009 19:39:36 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 19:39:36 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of allen44@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail10.dslextreme.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 01 Sep 2009 19:39:26 +0000 Received: (qmail 16021 invoked from network); 1 Sep 2009 19:39:05 -0000 Received: from unknown (HELO glsnet.net) (allen44@example.org@83.161.120.155) by mail10.dslextreme.com with SMTP; Tue, 01 Sep 2009 12:39:05 -0700 X-Spam-Score: -4.4 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on gls2 X-Spam-Level: X-Spam-Tokens: X-Spam-Preview: Hi Devs, A vote of mine does not count but I think I am leaning on a -1 here for a couple reasons. 1. in ap_release.h you have placed a restriction on just this sort of thing; [...] X-Spam-Report: * -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] Received: from [83.161.120.155] by glsnet.net with SMTP (EHLO [83.161.120.155]) (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (83.161.120.155)); Tue, 1 Sep 2009 12:38:40 -0700 Message-ID: <allen44@example.org> Date: Tue, 01 Sep 2009 12:38:54 -0700 From: "Gregg L. Smith" <allen44@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090812) MIME-Version: 1.0 To: allen44@example.org Subject: Re: svn commit: r808965 - signature spam and an existing restriction References: <allen44@example.org> In-Reply-To: <allen44@example.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-MagicMail-UUID: 1bbe2f64-972f-11de-bcc5-00188bf6df8c X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-4.4 required=6.3 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.7 Hi Devs, A vote of mine does not count but I think I am leaning on a -1 here for a couple reasons. 1. in ap_release.h you have placed a restriction on just this sort of thing; * "Product tokens should be short and to the point -- use of them for * advertizing or other non-essential information is explicitly forbidden." Granted, if someone wanted to, there is not much you can really do about it. What I might find as useful information you might just as well deem non-essential. BTW, advertising and essential are misspelled. Does handing the user a set of keys to do just this now negate this restriction or if it is still of concern, should this be added into the docs? 2. with mod_security this can already be done with the use of the SecServerSignature directive. http://www.modsecurity.org/documentation/modsecurity-apache/2.5.9/modsecurity2-apache-reference.html#N10B69 3. Not that Netcraft is a scientifically sound survey, I'd still hate to see Apache jump off the cliff. Just a sampling of random thoughts I had when I saw this. Regards, Gregg allen44@example.org wrote: > Author: jim > Date: Fri Aug 28 17:37:12 2009 > New Revision: 808965 > > URL: http://svn.apache.org/viewvc?rev=808965&view=rev > Log: > And additional ServerTokens improvement... > > Modified: > httpd/httpd/trunk/CHANGES > httpd/httpd/trunk/docs/manual/mod/core.xml > httpd/httpd/trunk/server/core.c > From allen44@example.org Tue Sep 01 20:17:14 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 7752 invoked from network); 1 Sep 2009 20:17:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 20:17:14 -0000 Received: (qmail 12081 invoked by uid 500); 1 Sep 2009 20:17:13 -0000 Delivered-To: allen44@example.org Received: (qmail 12014 invoked by uid 500); 1 Sep 2009 20:17:13 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 11806 invoked by uid 99); 1 Sep 2009 20:17:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 20:17:12 +0000 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO eru.sfritsch.de) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 20:17:03 +0000 Received: from k.lan ([83.161.120.155] helo=k.localnet) by eru.sfritsch.de with esmtp (Exim 4.63) (envelope-from <allen44@example.org>) id 1MiZmU-000611-05 for allen44@example.org; Tue, 01 Sep 2009 22:16:42 +0200 From: Stefan Fritsch <allen44@example.org> To: allen44@example.org Subject: Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach) Date: Tue, 1 Sep 2009 22:16:40 +0200 User-Agent: KMail/1.12.0 (Linux/2.6.30-1-686; KDE/4.3.0; i686; ; ) References: <allen44@example.org> <allen44@example.org> <allen44@example.org> In-Reply-To: <allen44@example.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <allen44@example.org> X-Virus-Checked: Checked by ClamAV on apache.org On Tuesday 01 September 2009, Ruediger Pluem wrote: > On 09/01/2009 04:26 PM, Torsten Foertsch wrote: > > On Tue 01 Sep 2009, Stefan Fritsch wrote: > >> http://www.sfritsch.de/mod_reqtimeout/mod_reqtimeout.c > >> > >> Any comments are welcome. > > > > Just a few thoughts: > > > > - You use GLOBAL_ONLY in ap_check_cmd_context. That means the > > directive must not appear in vhost context. AFAIK, > > conn->base_server reflects the vhost in a pre connection hook if > > it is IP-based. So, why don't you allow for RequestTimeout to be > > valid in ip-based vhost context? That way the protocol problem is > > solved, isn't it? > > > > - Wouldn't RequestTimeout better be named RequestHeaderTimeout or > > ReadRequestHeaderTimeout? RequestTimeout is a bit missleading > > (IMHO). My first thought was: That thing limits the whole > > transaction. > > Nice module. +1 to the comments above. Thanks to everyone commenting so far. I have changed these two things and uploaded the new version to the same place. Stefan From allen44@example.org Tue Sep 01 20:19:52 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 8229 invoked from network); 1 Sep 2009 20:19:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 20:19:52 -0000 Received: (qmail 14468 invoked by uid 500); 1 Sep 2009 20:19:51 -0000 Delivered-To: allen44@example.org Received: (qmail 14387 invoked by uid 500); 1 Sep 2009 20:19:51 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 14378 invoked by uid 99); 1 Sep 2009 20:19:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 20:19:51 +0000 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [83.161.120.155] (HELO eru.sfritsch.de) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 20:19:42 +0000 Received: from k.lan ([83.161.120.155] helo=k.localnet) by eru.sfritsch.de with esmtp (Exim 4.63) (envelope-from <allen44@example.org>) id 1MiZp4-00061c-7C for allen44@example.org; Tue, 01 Sep 2009 22:19:22 +0200 From: Stefan Fritsch <allen44@example.org> To: allen44@example.org Subject: Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach) Date: Tue, 1 Sep 2009 22:19:20 +0200 User-Agent: KMail/1.12.0 (Linux/2.6.30-1-686; KDE/4.3.0; i686; ; ) References: <allen44@example.org> <allen44@example.org> <allen44@example.org> In-Reply-To: <allen44@example.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <allen44@example.org> X-Virus-Checked: Checked by ClamAV on apache.org On Tuesday 01 September 2009, Ruediger Pluem wrote: > >>> - Apache should respond with HTTP_REQUEST_TIME_OUT and not > >>> HTTP_BAD_REQUEST when there is a timeout reading the request. > >> > >> In the slowloris case, it needs to time out before there's any > >> such thing as an HTTP request, so it won't be sending an HTTP > >> response. But I guess you're talking about the body timeout? > > > > No, about the request. When apache has received at least one line > > of the request, it currently responds with HTTP_BAD_REQUEST when > > there is a timeout before the complete request was read. In this > > case HTTP_REQUEST_TIME_OUT is more appropriate. It means "the > > client did not produce a request within the time that the server > > was prepared to wait". > > Is this just regarding better logging on the server side? Otherwise > I wouldn't care too much what we sent to an attacker. Well, if there is a legitimate client who is too slow, it's better to send him a meaningful error message. But it's not that important, of course. From allen44@example.org Tue Sep 01 20:27:43 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 9876 invoked from network); 1 Sep 2009 20:27:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 20:27:43 -0000 Received: (qmail 21533 invoked by uid 500); 1 Sep 2009 20:27:42 -0000 Delivered-To: allen44@example.org Received: (qmail 21451 invoked by uid 500); 1 Sep 2009 20:27:42 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 21442 invoked by uid 99); 1 Sep 2009 20:27:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 20:27:42 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO minotaur.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 01 Sep 2009 20:27:32 +0000 Received: (qmail 9820 invoked by uid 2161); 1 Sep 2009 20:27:11 -0000 Received: from [83.161.120.155] (euler.heimnetz.de [83.161.120.155]) by cerberus.heimnetz.de (Postfix on SuSE Linux 7.0 (i386)) with ESMTP id 10F3D1721C for <allen44@example.org>; Tue, 1 Sep 2009 22:26:58 +0200 (CEST) Message-ID: <allen44@example.org> Date: Tue, 01 Sep 2009 22:27:12 +0200 From: Ruediger Pluem <allen44@example.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:83.161.120.155) Gecko/20090606 SeaMonkey/1.1.17 MIME-Version: 1.0 To: allen44@example.org Subject: Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach) References: <allen44@example.org> <allen44@example.org> <allen44@example.org> <allen44@example.org> In-Reply-To: <allen44@example.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org On 09/01/2009 10:16 PM, Stefan Fritsch wrote: > On Tuesday 01 September 2009, Ruediger Pluem wrote: >> On 09/01/2009 04:26 PM, Torsten Foertsch wrote: >>> On Tue 01 Sep 2009, Stefan Fritsch wrote: >>>> http://www.sfritsch.de/mod_reqtimeout/mod_reqtimeout.c >>>> >>>> Any comments are welcome. >>> Just a few thoughts: >>> >>> - You use GLOBAL_ONLY in ap_check_cmd_context. That means the >>> directive must not appear in vhost context. AFAIK, >>> conn->base_server reflects the vhost in a pre connection hook if >>> it is IP-based. So, why don't you allow for RequestTimeout to be >>> valid in ip-based vhost context? That way the protocol problem is >>> solved, isn't it? >>> >>> - Wouldn't RequestTimeout better be named RequestHeaderTimeout or >>> ReadRequestHeaderTimeout? RequestTimeout is a bit missleading >>> (IMHO). My first thought was: That thing limits the whole >>> transaction. >> Nice module. +1 to the comments above. > > Thanks to everyone commenting so far. I have changed these two things > and uploaded the new version to the same place. Thanks for the update. I guess reqtimeout_after_body also needs to be updated to the assert / do nothing if not configured logic like reqtimeout_after_headers Regards Rüdiger From allen44@example.org Tue Sep 01 20:41:41 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 12708 invoked from network); 1 Sep 2009 20:41:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 20:41:40 -0000 Received: (qmail 41837 invoked by uid 500); 1 Sep 2009 20:41:39 -0000 Delivered-To: allen44@example.org Received: (qmail 41763 invoked by uid 500); 1 Sep 2009 20:41:39 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 41754 invoked by uid 99); 1 Sep 2009 20:41:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 20:41:39 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [83.161.120.155] (HELO smtpauth12.prod.mesa1.secureserver.net) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 01 Sep 2009 20:41:29 +0000 Received: (qmail 12101 invoked from network); 1 Sep 2009 20:41:05 -0000 Received: from unknown (83.161.120.155) by smtpauth12.prod.mesa1.secureserver.net (83.161.120.155) with ESMTP; 01 Sep 2009 20:41:04 -0000 Message-ID: <allen44@example.org> Date: Tue, 01 Sep 2009 15:40:28 -0500 From: "William A. Rowe, Jr." <allen44@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090812) MIME-Version: 1.0 To: allen44@example.org Subject: Re: svn commit: r808966 - in /httpd/httpd/trunk/docs/manual/mod: core.html.en core.xml.de core.xml.ja core.xml.tr References: <allen44@example.org> In-Reply-To: <allen44@example.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org allen44@example.org wrote: > --- httpd/httpd/trunk/docs/manual/mod/core.html.en (original) > +++ httpd/httpd/trunk/docs/manual/mod/core.html.en Fri Aug 28 17:39:08 2009 > @@ -2932,6 +2932,14 @@ > <dd>Server sends (<em>e.g.</em>): <code>Server: Apache/2.0.41 > (Unix)</code></dd> > > + <dt><code>ServerTokens Set <em>"String"</em></code></dt> > + > + <dd>Server sends user specified string > + (<em>e.g.</em>): <code>Server: MyWebServer/8.6</code><br /> > + <strong>Note:</strong> The string must be in quotes if > + there are any embedded spaces. > + </dd> > + Off? That was a bit hard to stomach, and it seems odd that a long standing policy of presenting clients with usable *negotiation* data, unless they choose to patch their server, would be usurped without a decision by the dev@ list to reverse this policy. If it is reversed, I'm fine with disabling it. But unless "Apache Software Foundation httpd Server" *has been patched*, it remains "Apache" for purposes of identifying the server-agent. Unequivocally -1. Now if you wanted to build a descriptive tag representing a combination of modules, etc, with an *additional* token (just as modules add), then ServerTokens Add of an arbitrary token/token representation is reasonable. E.g. Server: Apache/2.2.12 mod_dav/2.2.12 mod_security/1.8.9 JaguNET/1.0.0 is a perfectly reasonable server string. And I have run into the situation where we used cgi to implement a proxy, where the Via, Date and Server were legitimately different than httpd's force-override-behavior. I'd be happy to see changes that permit applications to convey appropriate values to the user-agent, and have proposed this once before. If there is a détente in our rigid control of the Server: tokens, this might be the time to bring it up. From allen44@example.org Tue Sep 01 21:12:03 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 20835 invoked from network); 1 Sep 2009 21:12:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 21:12:03 -0000 Received: (qmail 67061 invoked by uid 500); 1 Sep 2009 21:12:02 -0000 Delivered-To: allen44@example.org Received: (qmail 66958 invoked by uid 500); 1 Sep 2009 21:12:02 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 66949 invoked by uid 99); 1 Sep 2009 21:12:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 21:12:02 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [83.161.120.155] (HELO p3plsmtpa01-03.prod.phx3.secureserver.net) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 01 Sep 2009 21:11:51 +0000 Received: (qmail 23866 invoked from network); 1 Sep 2009 21:11:29 -0000 Received: from unknown (83.161.120.155) by p3plsmtpa01-03.prod.phx3.secureserver.net (83.161.120.155) with ESMTP; 01 Sep 2009 21:11:28 -0000 Message-ID: <allen44@example.org> Date: Tue, 01 Sep 2009 16:10:52 -0500 From: "William A. Rowe, Jr." <allen44@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090812) MIME-Version: 1.0 To: allen44@example.org Subject: Re: vote on concept of ServerTokens Off References: <allen44@example.org> <allen44@example.org> <allen44@example.org> <allen44@example.org> In-Reply-To: <allen44@example.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------050508070309050103080607" X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------050508070309050103080607 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Ruediger Pluem wrote: > > On 12/05/2006 07:16 PM, Jim Jagielski wrote: >> On Dec 5, 2006, at 7:23 AM, Joe Orton wrote: >> >>> On Tue, Dec 05, 2006 at 06:39:30AM -0500, Jeff Trawick wrote: >>> >>>> A lot of opinions were offered back in August. Some were negative but >>>> I don't see anything that looks like a veto. >>>> >>>> (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/% >>>> allen44@example.org%3e) >>>> >>>> A concern with the logging of server version has since been resolved, >>>> but implementation of the original feature died. Before Sebastian >>>> Nohn's patch is revised to fit in with the subsequent changes, I'd >>>> like to confirm that nobody has a strong (veto) objection to the >>>> feature, and that those in favor clearly out number those against. >>> >>> +1. Should be documented as "a bad idea" as Joshua notes in that >>> thread. >>> >> +1 (with that condition) > > +1 provided the condition above is true. Jim, when you committed ServerTokens Set, you did not address this concern expressed by a significant number of project members. http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/manual/mod/core.xml also has an error in the <syntax>, it doesn't appear that you updated it. Jeff even offered a draft :) --------------050508070309050103080607 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Attached Message" X-Account-Key: account5 Return-Path: <allen44@example.org> Received: from mail.apache.org (hermes.apache.org [83.161.120.155]) by retribution.cnchost.com (ConcentricHost(3.4) MX) with SMTP id 5E10029421 for <allen44@example.org>; Wed, 6 Dec 2006 13:44:25 -0500 (EST) Received: (qmail 80044 invoked by uid 500); 6 Dec 2006 18:44:21 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 80026 invoked by uid 99); 6 Dec 2006 18:44:21 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Dec 2006 10:44:21 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of allen44@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO nf-out-0910.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Dec 2006 10:44:11 -0800 Received: by nf-out-0910.google.com with SMTP id p77so682859nfc for <allen44@example.org>; Wed, 06 Dec 2006 10:43:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Pzw0zrYuSHkv4FpF0+a63ds6dJYR+MvDzSXXXT0aX4xCm9ZzcTd2kBjfIkyAC0IRccRNTjATVqYyirIZVTlX8C9Q4GeVQn2sVNUubVikmV/623h6VqinxOKmmOlKjmGjLpVQ2LkjjN95/vzHRHOUEEzrjJj0riX1h0Uqs3ybnUg= Received: by 83.161.120.155 with SMTP id l6mr282360buc.1165430629937; Wed, 06 Dec 2006 10:43:49 -0800 (PST) Received: by 83.161.120.155 with HTTP; Wed, 6 Dec 2006 10:43:49 -0800 (PST) Message-ID: <allen44@example.org> Date: Wed, 6 Dec 2006 13:43:49 -0500 From: "Jeff Trawick" <allen44@example.org> To: allen44@example.org Subject: Re: vote on concept of ServerTokens Off In-Reply-To: <allen44@example.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <allen44@example.org> <allen44@example.org> <allen44@example.org> <allen44@example.org> X-Virus-Checked: Checked by ClamAV on apache.org T24gMTIvNi8wNiwgUGF1bCBRdWVybmEgPGNoaXBAZm9yY2UtZWxpdGUuY29tPiB3cm90ZToN Cgo+IFRoaXMgdGhyZWFkIGlzIG1ha2luZyBtZSBzYWQuDQoKTm8gdGVhcnMgOykgIFRoZSBz b21ld2hhdCBicmlnaHQgc2lkZSBpcyB0aGF0IHB1c2hpbmcgb24gdGhpcyB0ZW5kZXINCnNw b3QgdW50aWwgaXQgaHVydHMgc2hvdWxkIGF0IHRoZSB2ZXJ5IGxlYXN0IGF2b2lkIGhhdmlu ZyB0aGUgc2FtZQ0KZGlzY3Vzc2lvbiBoZXJlIGZvciB0aGUgbmV4dCBjb3VwbGUgb2YgeWVh cnMsIGFuZCBhdCB0aGUgbW9zdCBjYW4NCmF2b2lkIGEgbG90IG9mIG90aGVyIHdhc3RlZnVs IGRpc2N1c3Npb25zIHBlcm1hbmVudGx5IDspICBUaGUgbWlkZGxlDQpncm91bmQgb2YgZG9j dW1lbnQgZXhwbGljaXRseSB3aHkgeW91IGNhbid0IGRpcmVjdGx5IHR1cm4gaXQgb2ZmDQpz aG91bGQgYWxzbyBiZSBhY2hpZXZhYmxlLg0KClByb3Bvc2VkIGRvY3VtZW50YXRpb24gZm9y IHRoZSBTZXJ2ZXJUb2tlbnMgZGlyZWN0aXZlLg0KClNwZWNpYWwgbm90ZToNCgpBcGFjaGUg SFRUUCBTZXJ2ZXIgdXNlcnMgc3VnZ2VzdCBmcm9tIHRpbWUgdG8gdGltZSB0aGF0IHRoZQ0K U2VydmVyVG9rZW5zIGRpcmVjdGl2ZSBhbGxvdyB0aGUgU2VydmVyIHJlc3BvbnNlIGhlYWRl ciB0byBiZQ0KZWxpbWluYXRlZCBjb21wbGV0ZWx5LiAgVGhpcyBmZWF0dXJlIHN1Z2dlc3Rp b24gaXMgcmVqZWN0ZWQgZm9yIHRoZQ0KZm9sbG93aW5nIHJlYXNvbnM6DQoKKiBUaGUgQXBh Y2hlIEhUVFAgU2VydmVyIHByb2plY3Qgd2FudHMgc3VydmV5cyBvZiB3ZWIgc2VydmVyIHVz YWdlLA0Kc3VjaCBhcyB0aGUgd2VsbC1rbm93biBOZXRjcmFmdCBzdXJ2ZXksIHRvIG1vcmUg YWNjdXJhdGVseSByZXByZXNlbnQNCnRoZSBhY3R1YWwgdXNlIG9mIEFwYWNoZSBodHRwZC4g IFdoaWxlIHNvbWUgd2ViIHNlcnZlciBhZG1pbmlzdHJhdG9ycw0KY3VycmVudGx5IG1vZGlm eSB0aGUgQXBhY2hlIEhUVFAgU2VydmVyIHNvdXJjZSBjb2RlIG9yIGluc3RhbGwNCnRoaXJk LXBhcnR5IG1vZHVsZXMgd2hpY2ggY2FuIHJlbW92ZSB0aGUgU2VydmVyIGhlYWRlciwgdG9v IGZldw0KYWRtaW5pc3RyYXRvcnMgZG8gdGhpcyB0byBzaWduaWZpY2FudGx5IGFsdGVyIHRo ZSByZXN1bHRzLiAgVGhlIHNhbWUNCm1heSBub3QgYmUgdHJ1ZSBpZiBpdCBpcyBhbiBlYXNp bHktYWNjZXNzaWJsZSBmZWF0dXJlLg0KCiogVGhlIEFwYWNoZSBIVFRQIFNlcnZlciBwcm9q ZWN0IGJlbGlldmVzIHRoYXQgbW9zdCBwZW9wbGUgd2hvIHdhbnQgdG8NCmF2b2lkIHNlbmRp bmcgdGhlIFNlcnZlciBoZWFkZXIgbWlzdGFrZW5seSB0aGluayB0aGF0IGRvaW5nIHNvIG1h eQ0KcHJvdGVjdCB0aGVpciBzZXJ2ZXIgZnJvbSBhdHRhY2tzIGJhc2VkIG9uIGtub3duIGZs YXdzIGluIG9sZGVyIEFwYWNoZQ0KSFRUUEQgcmVsZWFzZXMsIHdoZW4gaW4gZmFjdCB0aGUg b25seSByZWFzb25hYmxlIHdheSB0byBhZGRyZXNzIHRoZXNlDQpmbGF3cyBpcyB0byB1cGdy YWRlIHRvIG5ldyBBcGFjaGUgSFRUUEQgcmVsZWFzZXMgd2hpY2ggY29ycmVjdA0Kc2VjdXJp dHkgcHJvYmxlbXMgYWZmZWN0aW5nIHlvdXIgY29uZmlndXJhdGlvbi4gIEJ5IHJlc3RyaWN0 aW5nIHRoZQ0KYWJpbGl0eSB0byBjb25maWd1cmUgQXBhY2hlIGluIHRoaXMgbWFubmVyLCB3 ZSB3aXNoIHRvIHJhaXNlIGF3YXJlbmVzcw0Kb2YgdGhlIG5lZWQgdG8gdXBncmFkZSB3aGVu IGNyaXRpY2FsIHZ1bG5lcmFiaWxpdGllcyBhcmUgYWRkcmVzc2VkLg0KCih3aGF0IG90aGVy IHJlYXNvbnMgZ28gaGVyZT8pDQouDQoK --------------050508070309050103080607-- From allen44@example.org Tue Sep 01 21:12:49 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 21004 invoked from network); 1 Sep 2009 21:12:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 21:12:49 -0000 Received: (qmail 68086 invoked by uid 500); 1 Sep 2009 21:12:48 -0000 Delivered-To: allen44@example.org Received: (qmail 68008 invoked by uid 500); 1 Sep 2009 21:12:47 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 67999 invoked by uid 99); 1 Sep 2009 21:12:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 21:12:47 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [83.161.120.155] (HELO p3plsmtpa01-09.prod.phx3.secureserver.net) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 01 Sep 2009 21:12:37 +0000 Received: (qmail 8470 invoked from network); 1 Sep 2009 21:12:15 -0000 Received: from unknown (83.161.120.155) by p3plsmtpa01-09.prod.phx3.secureserver.net (83.161.120.155) with ESMTP; 01 Sep 2009 21:12:15 -0000 Message-ID: <allen44@example.org> Date: Tue, 01 Sep 2009 16:11:39 -0500 From: "William A. Rowe, Jr." <allen44@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090812) MIME-Version: 1.0 To: allen44@example.org Subject: Re: vote on concept of ServerTokens Off References: <allen44@example.org> In-Reply-To: <allen44@example.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Jim Jagielski wrote: > Lars Eilebrecht wrote: >> According to Jeff: >> >>> A lot of opinions were offered back in August. Some were negative but >>> I don't see anything that looks like a veto. >> I voted -1 at that time which is a veto. >> >> My opinion hasn't changed and I still think that it is a very >> stupid idea to add a "feature" that allows our users to do >> something which is stupid and absurd. >> >> *shrug* but as everyone seems to think that this is a good idea, >> feel free to ignore my veto. > > A Veto is a Veto. If you feel strongly enough about it, then > it cannot be, and should not be, ignored. Lars, yours is the last veto standing for ServerTokens Off. What say you? (Your veto would appear to imply a veto of any ServerTokens Set syntax). Bill From allen44@example.org Tue Sep 01 21:37:44 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 28956 invoked from network); 1 Sep 2009 21:37:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 21:37:44 -0000 Received: (qmail 95649 invoked by uid 500); 1 Sep 2009 21:37:42 -0000 Delivered-To: allen44@example.org Received: (qmail 95571 invoked by uid 500); 1 Sep 2009 21:37:42 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 95562 invoked by uid 99); 1 Sep 2009 21:37:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 21:37:42 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [83.161.120.155] (HELO smtpout07.prod.mesa1.secureserver.net) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 01 Sep 2009 21:37:32 +0000 Received: (qmail 6816 invoked from network); 1 Sep 2009 21:37:10 -0000 Received: from unknown (83.161.120.155) by smtpout07.prod.mesa1.secureserver.net (83.161.120.155) with ESMTP; 01 Sep 2009 21:37:10 -0000 Message-ID: <allen44@example.org> Date: Tue, 01 Sep 2009 16:36:34 -0500 From: "William A. Rowe, Jr." <allen44@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090812) MIME-Version: 1.0 To: "allen44@example.org" <allen44@example.org> Subject: [Fwd: Re: vote on concept of ServerTokens Off] X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Why attach email doesn't work in thunderbird is beyond me... This was Jeff's starting point for documenting ServerTokens Off. -------- Original Message -------- Subject: Re: vote on concept of ServerTokens Off Date: Wed, 6 Dec 2006 13:43:49 -0500 From: Jeff Trawick <allen44@example.org> Reply-To: allen44@example.org To: allen44@example.org References: <allen44@example.org> <allen44@example.org> <allen44@example.org> <allen44@example.org> On 12/6/06, Paul Querna <allen44@example.org> wrote: > This thread is making me sad. No tears ;) The somewhat bright side is that pushing on this tender spot until it hurts should at the very least avoid having the same discussion here for the next couple of years, and at the most can avoid a lot of other wasteful discussions permanently ;) The middle ground of document explicitly why you can't directly turn it off should also be achievable. Proposed documentation for the ServerTokens directive. Special note: Apache HTTP Server users suggest from time to time that the ServerTokens directive allow the Server response header to be eliminated completely. This feature suggestion is rejected for the following reasons: * The Apache HTTP Server project wants surveys of web server usage, such as the well-known Netcraft survey, to more accurately represent the actual use of Apache httpd. While some web server administrators currently modify the Apache HTTP Server source code or install third-party modules which can remove the Server header, too few administrators do this to significantly alter the results. The same may not be true if it is an easily-accessible feature. * The Apache HTTP Server project believes that most people who want to avoid sending the Server header mistakenly think that doing so may protect their server from attacks based on known flaws in older Apache HTTPD releases, when in fact the only reasonable way to address these flaws is to upgrade to new Apache HTTPD releases which correct security problems affecting your configuration. By restricting the ability to configure Apache in this manner, we wish to raise awareness of the need to upgrade when critical vulnerabilities are addressed. (what other reasons go here?) . From allen44@example.org Tue Sep 01 23:11:28 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 56739 invoked from network); 1 Sep 2009 23:11:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 23:11:27 -0000 Received: (qmail 98257 invoked by uid 500); 1 Sep 2009 23:11:26 -0000 Delivered-To: allen44@example.org Received: (qmail 98175 invoked by uid 500); 1 Sep 2009 23:11:26 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 98166 invoked by uid 99); 1 Sep 2009 23:11:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 23:11:26 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO smtpauth22.prod.mesa1.secureserver.net) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 01 Sep 2009 23:11:16 +0000 Received: (qmail 31286 invoked from network); 1 Sep 2009 23:10:55 -0000 Received: from unknown (83.161.120.155) by smtpauth22.prod.mesa1.secureserver.net (83.161.120.155) with ESMTP; 01 Sep 2009 23:10:54 -0000 Message-ID: <allen44@example.org> Date: Tue, 01 Sep 2009 18:10:17 -0500 From: "William A. Rowe, Jr." <allen44@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090812) MIME-Version: 1.0 To: allen44@example.org Subject: Re: svn commit: r795451 - /httpd/httpd/branches/2.2.x/STATUS References: <allen44@example.org> <allen44@example.org> In-Reply-To: <allen44@example.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Nick... should we discuss an alternate name? Or should I simply revert the patch vetoed on trunk? I'm neutral on the outcome, since I don't see what this directive offers which an ErrorDocument would not, but I'm also ok with it persisting with an appropriate directive name. Ignoring a veto entirely isn't cool, erasing it is even less appropriate, and it's stood for an awfully long time now. Can we compromise on the name NotFoundHandler, MissingFileHandler, NotFoundAction, MissingFileAction, or any of a dozen other possible variations that don't contain the misleading word "Default"? > "Hander" was not the bad choice. > > "Default" is the bad choice. > > http://www.merriam-webster.com/dictionary/default > See 5 b, it's meaning is crystal clear... > > 5 b: a selection automatically used by a computer program in the > absence of a choice made by the user > > In the httpd context, "Default" refers to a setting or action which is > applied in the absence of any configuration setting. That is not what > your patch does. > > For this to be a "Default" behavior, all content, existing or not found, > must be processed by this handler. We have such a directive in mod_alias, > which is the Action directive. > > FallbackHandler, FallbackAction, there are a host of directive names you > could choose that do *not imply* that the behavior affects all requests > which aren't otherwise configured. > > This directive also belongs in mod_actions. > http://httpd.apache.org/docs/2.2/mod/mod_actions.html > > Please restore my veto, thanks. > > Bill > > From allen44@example.org Tue Sep 01 23:30:33 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 61511 invoked from network); 1 Sep 2009 23:30:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Sep 2009 23:30:33 -0000 Received: (qmail 19024 invoked by uid 500); 1 Sep 2009 23:30:32 -0000 Delivered-To: allen44@example.org Received: (qmail 18924 invoked by uid 500); 1 Sep 2009 23:30:32 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 18915 invoked by uid 99); 1 Sep 2009 23:30:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 23:30:32 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO opensolaris) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 23:30:24 +0000 Received: from [83.161.120.155] (opensolaris.local [83.161.120.155]) by opensolaris (8.14.3+Sun/8.14.3) with ESMTP id n81NTw5H005086 for <allen44@example.org>; Wed, 2 Sep 2009 00:30:01 +0100 (BST) Message-ID: <allen44@example.org> Date: Wed, 02 Sep 2009 00:29:58 +0100 From: Nick Kew <allen44@example.org> User-Agent: Thunderbird 83.161.120.155 (X11/20090323) MIME-Version: 1.0 To: allen44@example.org Subject: Re: svn commit: r795451 - /httpd/httpd/branches/2.2.x/STATUS References: <allen44@example.org> <allen44@example.org> <allen44@example.org> In-Reply-To: <allen44@example.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org William A. Rowe, Jr. wrote: > Nick... > > should we discuss an alternate name? Or should I simply revert the patch > vetoed on trunk? I'm easy on the name. Let's ping DrBacchus - this was his feature request :-) > Can we compromise on the name NotFoundHandler, MissingFileHandler, > NotFoundAction, MissingFileAction, or any of a dozen other possible > variations that don't contain the misleading word "Default"? FWIW, I preferred your earlier suggestion of Fallback[Handler|Action]. -- Nick Kew From allen44@example.org Wed Sep 02 02:13:36 2009 Return-Path: <allen44@example.org> Delivered-To: allen44@example.org Received: (qmail 98546 invoked from network); 2 Sep 2009 02:13:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Sep 2009 02:13:36 -0000 Received: (qmail 31760 invoked by uid 500); 2 Sep 2009 02:13:35 -0000 Delivered-To: allen44@example.org Received: (qmail 31670 invoked by uid 500); 2 Sep 2009 02:13:35 -0000 Mailing-List: contact allen44@example.org; run by ezmlm Precedence: bulk Reply-To: allen44@example.org list-help: <mailto:allen44@example.org> list-unsubscribe: <mailto:allen44@example.org> List-Post: <mailto:allen44@example.org> List-Id: <dev.httpd.apache.org> Delivered-To: mailing list allen44@example.org Received: (qmail 31661 invoked by uid 99); 2 Sep 2009 02:13:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Sep 2009 02:13:34 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO smtpauth21.prod.mesa1.secureserver.net) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 02 Sep 2009 02:13:25 +0000 Received: (qmail 13218 invoked from network); 2 Sep 2009 02:13:04 -0000 Received: from unknown (83.161.120.155) by smtpauth21.prod.mesa1.secureserver.net (83.161.120.155) with ESMTP; 02 Sep 2009 02:13:03 -0000 Message-ID: <allen44@example.org> Date: Tue, 01 Sep 2009 21:12:27 -0500 From: "William A. Rowe, Jr." <allen44@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090812) MIME-Version: 1.0 To: allen44@example.org Subject: Re: svn commit: r795451 - /httpd/httpd/branches/2.2.x/STATUS References: <allen44@example.org> <allen44@example.org> <allen44@example.org> <allen44@example.org> In-Reply-To: <allen44@example.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Nick Kew wrote: > William A. Rowe, Jr. wrote: >> Nick... >> >> should we discuss an alternate name? Or should I simply revert the patch >> vetoed on trunk? > > I'm easy on the name. > >
{'source': 'Apache Software Foundation Public Mail Archives'}