Re: mod_deflate DoS using HEAD

2010-06-22 Thread Ruediger Pluem 


On 06/21/2010 11:37 PM, William A. Rowe Jr. wrote:
 On 6/21/2010 4:00 PM, Stefan Fritsch wrote:
 As I understand it, Rüdiger's patch may be better for caching but uses 
 more CPU cycles. But it uses way less CPU than no patch at all. 
 Therefore I propose to include that patch unless there is clear 
 consensus that Eric's patch is to be preferred.
 
 Not a significant number, and Rüdiger's patch gathered +1's from myself,
 gregames, nick is on the wall with a +.5 - I think your question is to
 Rüdiger, with the emphasis on 'what is your decision?' based on this
 last rather indecisive posting.

Does someone still have Eric's patch? Seems that I can't find it right now.

Regards

Rüdiger

Re: server-status and privacy

2010-06-22 Thread g...@schwicking.de 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

 I'm thinking about a patch that adjusts server-status/mod_status
 to have a public vs. private setting... Public would be to
 have IP addresses exposed as public info; private would be to
 not expose 'em (keep 'em private).

 Comments?

Just as a hint: i posted a patch about two weeks ago, that enables a
(sort of) privacy setting for the server-status. The patch adds a new
directive (ServerStatusHandlerName string) and enables the admin to
customize the handlername for the mod_status module.

That way, other users (in a shared hosting enviroment), can not simply use

SetHandler server-status

in their htaccess-files anymore. For us that does the trick.

- From my experience, no admin (knowingly) makes the server-status
available to the public (and of course shouldnt). It should be used by
admins to view the servers current load, child status, remote ips and
for example to investigate in heavy-load situations (etc.).

What point does a server-status have, if i cant see the remote ip (and
for example roughly sum them up), use the requested url shown to
reproduce some sort of error or see the status of the current apache
childs and realize, that too many are in WAIT?

- From my point of view, renaming/customizing the handler is sufficient
and my patch already does that :-).

regards
volker







-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwgZCQACgkQHaTGAGocg2KtFQCfaWzucPVij8bgZmdvx8uSYJJu
TKAAn3kQmxcgOXBo5tJk2yrhOV9rmNbj
=mjjR
-END PGP SIGNATURE-

Re: [ANNOUNCEMENT] Apache HTTP Server 2.3.6-alpha Released

2010-06-22 Thread Paul Smedley 
Hi All,

On Mon, 21 Jun 2010 16:21:02 UTC, Jim Jagielski j...@jagunet.com 
wrote:

   Apache HTTP Server 2.3.6-alpha Released

FWIW - with a little more 'massaging' than 2.2.15 - I got this 
compiling on OS2.  Will test if it works tomorrow if I get some free 
time.

-- 
Cheers,

Paul.

Re: mod_deflate DoS using HEAD

2010-06-22 Thread Eric Covener 
On Tue, Jun 22, 2010 at 2:37 AM, Ruediger Pluem rpl...@apache.org wrote:
 Does someone still have Eric's patch? Seems that I can't find it right now.

This is what I have, but I never got off the fence back then much less now:

Index: modules/filters/mod_deflate.c
===
--- modules/filters/mod_deflate.c   (revision 793619)
+++ modules/filters/mod_deflate.c   (working copy)
@@ -578,7 +578,7 @@
deflate_check_etag(r, gzip);

/* For a 304 response, only change the headers */
-if (r-status == HTTP_NOT_MODIFIED) {
+if (r-status == HTTP_NOT_MODIFIED || r-header_only) {
ap_remove_output_filter(f);
return ap_pass_brigade(f-next, bb);
}




-- 
Eric Covener
cove...@gmail.com

RE: mod_deflate DoS using HEAD

2010-06-22 Thread Plüm, Rüdiger, VF-Group 
 

 -Original Message-
 From: Eric Covener 
 Sent: Dienstag, 22. Juni 2010 15:33
 To: dev@httpd.apache.org
 Subject: Re: mod_deflate DoS using HEAD
 
 On Tue, Jun 22, 2010 at 2:37 AM, Ruediger Pluem 
 rpl...@apache.org wrote:
  Does someone still have Eric's patch? Seems that I can't 
 find it right now.
 
 This is what I have, but I never got off the fence back then 
 much less now:
 
 Index: modules/filters/mod_deflate.c
 ===
 --- modules/filters/mod_deflate.c   (revision 793619)
 +++ modules/filters/mod_deflate.c   (working copy)
 @@ -578,7 +578,7 @@
 deflate_check_etag(r, gzip);
 
 /* For a 304 response, only change the headers */
 -if (r-status == HTTP_NOT_MODIFIED) {
 +if (r-status == HTTP_NOT_MODIFIED || r-header_only) {
 ap_remove_output_filter(f);
 return ap_pass_brigade(f-next, bb);
 }
 
 

Thanks for that. I guess the patch is not complete for current trunk.
IMHO it should look like:

Index: modules/filters/mod_deflate.c
===
--- modules/filters/mod_deflate.c   (revision 955960)
+++ modules/filters/mod_deflate.c   (working copy)
@@ -562,7 +562,7 @@
  * send out the headers).
  */

-if (r-status != HTTP_NOT_MODIFIED) {
+if ((r-status != HTTP_NOT_MODIFIED)  !r-header_only) {
 ctx = f-ctx = apr_pcalloc(r-pool, sizeof(*ctx));
 ctx-bb = apr_brigade_create(r-pool, f-c-bucket_alloc);
 ctx-buffer = apr_palloc(r-pool, c-bufferSize);
@@ -616,7 +616,7 @@
 deflate_check_etag(r, gzip);

 /* For a 304 response, only change the headers */
-if (r-status == HTTP_NOT_MODIFIED) {
+if ((r-status == HTTP_NOT_MODIFIED) || r-header_only) {
 ap_remove_output_filter(f);
 return ap_pass_brigade(f-next, bb);
 }

I am currently +0 on wether to use the patch above or my original
proposal. Both have its pros and cons (Saving more CPU vs. be more
picky about caching and implement an RFC SHOULD).

Regards

Rüdiger

Compile buildmark.c with libtool?

2010-06-22 Thread Brian Havard 
While finishing off the OS/2 fixes for trunk I came across a problem
caused by the fact that, unlike everything else in the tree, buildmark.c
is NOT built using libtool. Is there any reason for this?

I'd like to make the following change if there isn't:

|Index: Makefile.in|
|===|
|--- Makefile.in(revision 956865)|
|+++ Makefile.in(working copy)|
|@@ -4,8 +4,8 @@ CLEAN_SUBDIRS = test|
| |
| PROGRAM_NAME = $(progname)|
| PROGRAM_SOURCES  = modules.c|
|-PROGRAM_LDADD= buildmark.o $(HTTPD_LDFLAGS)
$(PROGRAM_DEPENDENCIES) $(EXTRA_LIBS) $(AP_LIBS) $(LIBS)|
|-PROGRAM_PRELINK  = $(COMPILE) -c $(top_srcdir)/server/buildmark.c|
|+PROGRAM_LDADD= buildmark.lo $(HTTPD_LDFLAGS)
$(PROGRAM_DEPENDENCIES) $(EXTRA_LIBS) $(AP_LIBS) $(LIBS)|
|+PROGRAM_PRELINK  = $(LIBTOOL) --mode=compile $(COMPILE) -c
$(top_srcdir)/server/buildmark.c|
| PROGRAM_DEPENDENCIES = \|
|   server/libmain.la \|
|   $(BUILTIN_LIBS) \|

Re: server-status and privacy

2010-06-22 Thread Nicholas Sherlock 

On 22/06/2010 12:40 a.m., Jim Jagielski wrote:

There have been a few reports regarding how server-status leaks
info, mostly about our (the ASF's) open use of server-status and
how IP addresses are exposed.

I'm thinking about a patch that adjusts server-status/mod_status
to have a public vs. private setting... Public would be to
have IP addresses exposed as public info; private would be to
not expose 'em (keep 'em private).

Comments?


I can't believe when I informed apache.org of this issue 70 days ago, 
that the immediate response wasn't simply to disable server-status or 
restrict it to clients from within Apache's network. It is a completely 
unreasonable violation of your customer's privacy to broadcast their IP 
addresses and viewing habits.


I sat and sniffed server-status today for an hour and saw lots of 
interesting things. These people thought it was interesting too:


Client - Requests for /server-status?auto
'121.2.73.140', '2'
'204.232.198.45', '18'
'209.40.196.203', '261'
'217.193.165.235', '27'
'222.73.44.146', '10'
'222.73.45.200', '15'
'222.73.68.35', '7'
'222.73.86.253', '17'
'61.57.131.230', '100'
'62.49.67.115', '18'
'64.27.116.177', '3'
'67.188.126.141', '3'
'67.199.134.1', '62'
'68.87.42.115', '13'
'69.70.70.186', '12'
'74.103.140.133', '172'
'81.0.134.157', '1'
'92.106.225.35', '42'

Client - Requests for /server-status
'118.90.8.44', '550' - That's me
'119.63.88.205', '80'
'187.34.7.120', '1'
'217.193.165.235', '16'
'222.73.68.35', '1'
'60.195.252.106', '24'
'64.27.116.177', '12'
'68.87.42.115', '68'
'81.0.134.157', '37'
'92.106.225.35', '1'

Cheers,
Nicholas Sherlock