Re: [PATCH] mod_rewrite: set cookies
Brian Degenhardt wrote:
> --y0ulUmNC+osPPQO6
> Content-Type: text/plain; charset=us-ascii
>
> We've been using this patch at mp3.com for a while, I figured I'd
> forward-port it to apache 2.0 and send it to you folks. It duplicates
> the functionality of the [E=var:val] but sets cookies. A very basic
> example would be to set a cookie called 'lastvisited' containing the
> uri of the last page you visited on the site:
>
> RewriteRule (.*) - [CO=lastvisited:$1:.mp3.com]
>
> This could be used in conjuction with the mod_log_config
> '%{lastvisited}C' directive for a more robust referrer.
>
I comitted a slightly different version of this patch.
the main differences:
1. use r->request_time instead of time(null)
2. uses a pool instead of a static size array for the cookie
3. sets the cookie in headers_out not err_headers_out
as that doesn't really work with internal redirects
4. modified the XML documentation
Thanks for the patch
Ian
Re: 2.0.38-39 lockup problem ?
Sorry, didn't mean to sow seeds of confusion, that problem was fixed by an SSL specific fix (as Ryan mentioned). The backtrace just looked really familiar, and the scenario sounded very close. I was just wondering if there were a higher level problem that was being tickled in different ways. I just thought there was no sense fixing each of the symptoms if there is a bigger problem, but Ryan pointed out that it only *looked* the same. So, never mind... Greg Ames wrote: > "Paul J. Reder" wrote: > >>This looks exactly like the problem that Allan and I ran into when you >>tried to send a request to http://foo.bar.org:443 (i.e. insecure request >>over the secure port). It tried to generate an error and went into an >>infinte loop. >> > > Can you try that with current HEAD and let us know what happens? > > Thanks, > Greg > > > -- Paul J. Reder --- "The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure." -- Albert Einstein
Re: [PATCH httpd 1.2] chunk size overflow
> This patch should be sufficient to fix the security hole for most > versions of Apache httpd 1.2. Should we put it up on dist/httpd? It turns out that this small patch is sufficient to plug the hole on all 1.2 and 1.3.* versions up until 1.3.24 if mod_proxy is in use. I have placed it in the relevant dist/httpd/patches directories. It probably should have been sent to CERT along with the advisory, or at least linked from our info file. I'll leave that to others. Roy
Re: cvs commit: httpd-2.0/modules/http http_request.c
On Fri, Jun 21, 2002 at 04:02:52PM -0400, Greg Ames wrote:
> Justin Erenkrantz wrote:
>
> > Only where ap_status_drops_connection is true. The problem before
> > was that if you got a 404 and then got a 413 on the discard, it
> > would revert the status to a 404 and then try to read the body as
> > part of the handlers in serving the error page.
> >
> > We simply can not do that - so the status can't be 404 when we get a
> > 413 - it must be a 413. When we are supposed to drop the connection,
> > r->status *must* indicate that.
>
> OK, let's turn that around. Suppose we got a 413 first and then a 404. Which
> one should we believe? And how should our canned error message read in both
> cases?
The 413. I don't believe we have to tell them that we screwed up in
getting a 404 to the error page (I dislike the whole recursive error
thing anyway). IMHO, it doesn't add anything of value.
> We ought to be able to display both in the correct order in our canned error
> message, no matter which happens first. And it sounds like if *either* status
> wants to drop the connection, we should avoid reading the body. Since ap_die
> now resets r->connection->keepalive anytime ap_status_drops_connection is true
> for the input status, I think this change to
> ap_discard_request_body would work:
>
> --- modules/http/http_protocol.c19 Jun 2002 18:43:28 - 1.440
> +++ modules/http/http_protocol.c21 Jun 2002 19:41:00 -
> @@ -1882,7 +1882,7 @@
> *
> * This function is also a no-op on a subrequest.
> */
> -if (r->main || ap_status_drops_connection(r->status)) {
> +if (r->main || !r->connection->keepalive) {
> return OK;
> }
Hmm. I'm not sure if I like that or not. What if ap_die isn't
involved and the status is set to drop the connection? Perhaps
we could just add the closing of the socket as another
condition? -- justin
Re: [PATCH] Apache2 httpd.conf
On Fri, Jun 21, 2002 at 09:34:08AM -0700, Aaron Bannert wrote: > +1 for removing the mod-status and mod-info sections from the default > config entirely. In an ideal world there would be no default config, Blech. -0 on removing it from the default configuration. IMHO, it's useful - just leave it commented out. And, on the other topic, a big whopping -0 for splitting out our default config to multiple files. We've gone over this before and I'm totally against multiple default configuration files. And, the posted mod_deflate configuration is *way* too complicated. I'd just use: AddOutputFilterByType DEFLATE text/html My $.02. -- justin
Re: daedalus pegged
Cliff Woolley wrote: > > Well, I guess our security advisory worked. Daedalus is totally maxxed > out at 700 concurrent requests holy cripe! > (which I assume is the maxclients setting). yep. > MANY people downloading the new releases of Apache (expecially > 1.3.26.tar.gz and the win32 binary of the same version). > > Good to see our efforts taken seriously. It's back down to 560 now. We've got a bunch of headroom available on MaxClients, but I don't want to bump it up a huge amount at times like this without watching it closely. Thanks for the heads up. Greg
Re: cvs commit: httpd-2.0/modules/http http_request.c
Justin Erenkrantz wrote:
> Only where ap_status_drops_connection is true. The problem before
> was that if you got a 404 and then got a 413 on the discard, it
> would revert the status to a 404 and then try to read the body as
> part of the handlers in serving the error page.
>
> We simply can not do that - so the status can't be 404 when we get a
> 413 - it must be a 413. When we are supposed to drop the connection,
> r->status *must* indicate that.
OK, let's turn that around. Suppose we got a 413 first and then a 404. Which
one should we believe? And how should our canned error message read in both
cases?
We ought to be able to display both in the correct order in our canned error
message, no matter which happens first. And it sounds like if *either* status
wants to drop the connection, we should avoid reading the body. Since ap_die
now resets r->connection->keepalive anytime ap_status_drops_connection is true
for the input status, I think this change to
ap_discard_request_body would work:
--- modules/http/http_protocol.c19 Jun 2002 18:43:28 - 1.440
+++ modules/http/http_protocol.c21 Jun 2002 19:41:00 -
@@ -1882,7 +1882,7 @@
*
* This function is also a no-op on a subrequest.
*/
-if (r->main || ap_status_drops_connection(r->status)) {
+if (r->main || !r->connection->keepalive) {
return OK;
}
Greg
Re: daedalus pegged
On Fri, 21 Jun 2002, Cliff Woolley wrote: > Well, I guess our security advisory worked. Daedalus is totally maxxed > out at 700 concurrent requests (which I assume is the maxclients setting). And the coolest part of it all is that daedalus is barely even noticing the load. Totally bandwidth-limited. (Errr, sorry collab guys. ;) (jwoolley@daedalus)/x1/home/jwoolley$ top last pid: 81376; load averages: 1.19, 1.67, 1.92 up 59+15:32:41 10:02:21 845 processes: 4 running, 840 sleeping, 1 zombie CPU states: 13.0% user, 0.0% nice, 12.1% system, 3.9% interrupt, 71.1% idle Mem: 435M Active, 293M Inact, 236M Wired, 34M Cache, 112M Buf, 4104K Free Swap: 1000M Total, 1032K Used, 999M Free --Cliff
daedalus pegged
Well, I guess our security advisory worked. Daedalus is totally maxxed out at 700 concurrent requests (which I assume is the maxclients setting). MANY people downloading the new releases of Apache (expecially 1.3.26.tar.gz and the win32 binary of the same version). Good to see our efforts taken seriously. --Cliff
Re: Apache 2.0 - the right way to statically link third party modules?
On Fri, Jun 21, 2002 at 12:07:23PM -0400, Gregory (Grisha) Trubetskoy wrote: > P.S. Whatever happened to the apache-modules list? > http://httpd.apache.org/lists.html lists it as > [EMAIL PROTECTED], but that doesn't work. Works fine for me. Send a message to [EMAIL PROTECTED] -aaron
Re: [PATCH] Apache2 httpd.conf /2
On Fri, Jun 21, 2002 at 02:55:07PM +0200, Günter Knauf wrote: > Hi, > I've been asked now a couple of times for a configuration sample for mod_deflate; >and since mod_deflate is now a 'normal' module and no more experimental I think there >should be a sample in the httpd.conf; if you dont think so at least a sample as below >should appear in the docs to mod_deflate... I think this thing would be perfect for a document, or perhaps a collection of example configuration files. -aaron
Re: [PATCH] Apache2 httpd.conf
On Fri, Jun 21, 2002 at 10:26:46AM -0400, Joshua Slive wrote: > Günter Knauf wrote: > > >the patch doesnt enable the modules, just only it's easier to enable them > >with only removing one # at the load command...; also I'm more thinking of > >disabling the modules after I have already used them; and if I then comment > >the load command I must also comment six config lines per module because > >the config isnt blocked with IfModule... > > Ahhh, but you forget that not everyone uses DSO modules. Many people > compile the modules into the server, and for them the module is active > regardless of the LoadModule line. Right. It would be nice if we had one way to load a module, and another way to enable it. This is the same debate as using vs. . +1 for removing the mod-status and mod-info sections from the default config entirely. In an ideal world there would be no default config, since the server defaults would allow simple serving of static pages. Config parameters could then be added to extend or override the defaults, and there would be one way to configure the server (and not two as we have it now). -aaron
Apache 2.0 - the right way to statically link third party modules?
Could someone please give me a clue on where to look for information on statically linking third party modules in Apache 2.0? The --with-module option seems to expect there to be a *.c file under modules subdirectory. But if the module has multiple *.c files and requires additional includes and a library - what is the best way to handle it? In Apache 1.3 one could create a lib (using ar/ranlib), then copy it into the Apache source tree under modules, drop a Makefile.libdir, Makefile.tmpl and a libxxx.module file there. What is the equivalent of doing this in Apache 2.0, if any? P.S. Whatever happened to the apache-modules list? http://httpd.apache.org/lists.html lists it as [EMAIL PROTECTED], but that doesn't work. Thanks, Grisha
RE: [PATCH] Apache2 httpd.conf
unfortunately we have symlinks only on *nix platforms, so for all other platforms this isnt a solution... Guenter. > Better do the configs the 'debian way' then: > /etc/apache2/ containing: > apache2.conf : default config for running Apache2 minimally. > ports.conf : "Port 443" etc directives > httpd.conf : local site extra's > modules-available/ : containing a config file per module > modules-enabled/ : containing symlinks to the modules-available > directory > Now if you want a module enabled; you can symlink it, easy and obvious > configging for everybody ;) > The apache2.conf "includes" the ports.conf + httpd.conf + > modules-available ofcourse. > As for packagers, let your apache module depend on the main apache > package and install your module's > config into the available dir, then _ask_ the user if they want it > enabled at once.
RE: 2.0.38-39 lockup problem ?
> From: gregames [mailto:gregames] On Behalf Of Greg Ames > > "Paul J. Reder" wrote: > > > > This looks exactly like the problem that Allan and I ran into when you > > tried to send a request to http://foo.bar.org:443 (i.e. insecure request > > over the secure port). It tried to generate an error and went into an > > infinte loop. > > Can you try that with current HEAD and let us know what happens? While the problems were similar, they were not caused by the same code, and the SSL problem would not have been touched at all by this patch. The problem with mod_ssl was fixed a while ago, and it never touched the ap_die code. Basically, in mod_ssl's post_read_request phase, we check for a flag to determine if the request was HTTP over the HTTPS port. The problem is that if we find the flag, then we do an internal redirect, which also runs the post_read_request function. Because the flag wasn't cleared, we just returned another error, which caused another internal_redirect, which ran the same phase, etc. Ryan
Re: [PATCH] Apache2 httpd.conf
> Bill Stoddard wrote: > > > > Playing devil's advocate :-) mod_status and mod_info should NOT be loaded by >default. > > > > Agreed! Wouldn't this change set things up so that if someone does > a compile with mod_status and mod_info included, the resultant > config file would make them active? That was my understanding. > If not, then, well... (in my best Emily Latella voice)... "never mind" :) > You're right. If mod_status and mod_info are compiled in, this change would make them active. Not good. I am also a fan of minimalist config files. Bill
Re: [PATCH] Apache2 httpd.conf
Günter Knauf wrote: >>Ahhh, but you forget that not everyone uses DSO modules. Many people >>compile the modules into the server, and for them the module is active >>regardless of the LoadModule line. > > Ok, that was the point I missed and convinces me that it's not such a good idea >then... > > then let's make another suggestion: > let's create a modules.conf and move these configs into it, and perhaps also the >mod_deflate config; then this conf can easily be included from the httpd.conf, and >httpd.conf becomes simpler... Yes, I believe that on the docs list Rich was thinking about something along the lines of a conf/examples/ directory where we could put all sorts of config snippets. I don't think anyone would have a problem with that, although it shouldn't replace having good examples in the documentation. Joshua.
RE: [PATCH] Apache2 httpd.conf
Günter Knauf [mailto:[EMAIL PROTECTED]] wrote: > > Ahhh, but you forget that not everyone uses DSO modules. > Many people > > compile the modules into the server, and for them the > module is active > > regardless of the LoadModule line. > Ok, that was the point I missed and convinces me that it's > not such a good idea then... > > then let's make another suggestion: > let's create a modules.conf and move these configs into it, > and perhaps also the mod_deflate config; then this conf can > easily be included from the httpd.conf, and httpd.conf > becomes simpler... Better do the configs the 'debian way' then: /etc/apache2/ containing: apache2.conf : default config for running Apache2 minimally. ports.conf : "Port 443" etc directives httpd.conf : local site extra's modules-available/ : containing a config file per module modules-enabled/ : containing symlinks to the modules-available directory Now if you want a module enabled; you can symlink it, easy and obvious configging for everybody ;) The apache2.conf "includes" the ports.conf + httpd.conf + modules-available ofcourse. As for packagers, let your apache module depend on the main apache package and install your module's config into the available dir, then _ask_ the user if they want it enabled at once. Greets, Jeroen
Re: 2.0.38-39 lockup problem ?
"Paul J. Reder" wrote: > > This looks exactly like the problem that Allan and I ran into when you > tried to send a request to http://foo.bar.org:443 (i.e. insecure request > over the secure port). It tried to generate an error and went into an > infinte loop. Can you try that with current HEAD and let us know what happens? Thanks, Greg
Re: [PATCH] Apache2 httpd.conf
> Ahhh, but you forget that not everyone uses DSO modules. Many people > compile the modules into the server, and for them the module is active > regardless of the LoadModule line. Ok, that was the point I missed and convinces me that it's not such a good idea then... then let's make another suggestion: let's create a modules.conf and move these configs into it, and perhaps also the mod_deflate config; then this conf can easily be included from the httpd.conf, and httpd.conf becomes simpler... Guenter.
Apache 2.0 developer documentation
Greetings, I've started playing with apache 2.0 with respect to writing modules and I was wondering if there was an ETA for more relavent up to date documentation for developers. Many of the documents including the API document have disclaimers saying "Warning: This document has not been updated to take into account changes made in the 2.0 version of the Apache HTTP Server. Some of the information may still be relevant, but please use it with care." Noah Arliss
Re: [PATCH] Apache2 httpd.conf
On Fri, 21 Jun 2002, [ISO-8859-1] Günter Knauf wrote: > the patch doesnt enable the modules, just only it's easier to enable > them with only removing one # at the load command...; That assumes you compile DSO's. > also I'm more thinking of disabling the modules after I have already > used them; and if I then comment the load command I must also comment > six config lines per module because the config isnt blocked with > IfModule... Well, THAT could be fixed, sure. :) But I'm iffy on whether it should be because I agree with Joshua that too many IfModule's just makes things hard to understand. --Cliff
Re: [PATCH] Apache2 httpd.conf
Günter Knauf wrote: > the patch doesnt enable the modules, just only it's easier to enable them with only >removing one # at the load command...; also I'm more thinking of disabling the >modules after I have already used them; and if I then comment the load command I must >also comment six config lines per module because the config isnt blocked with >IfModule... Ahhh, but you forget that not everyone uses DSO modules. Many people compile the modules into the server, and for them the module is active regardless of the LoadModule line. > why should somebody load the modules and waste memory if he doesnt use them?? And >again: the patch makes it erasier to enable / disable the modules, it does _NOT_ >enable them by default. What people "should" do and what people actually do are very different things. Many people have many superfluous modules in their build, and we need to make sure that it doesn't hurt them too badly. Joshua.
Re: [PATCH] Apache2 httpd.conf
Bill Stoddard wrote: > > Playing devil's advocate :-) mod_status and mod_info should NOT be loaded by >default. True. But even if they aren't, adding them in active sections in the default config is too dangerous in my opinion. Those are security-sensitive modules, and there is absolutely no way to know that the security policy that we have in the default config is anywhere near what is needed by any particular site. I might be willing to bend a little if it was changed to "Allow from 127.0.0.1", but even then, I don't think it is a good idea. Two general points: - I don't believe that it is a good practice to have the configuration of the server changed by simply adding a module. It should require an active change to httpd.conf to change the configuration. (We violate this policy already in some case; for example, mod_unique_id does its work regardless of the config file.) - sections need to be used very carefully in the default config. They seem to be misunderstood by users. For example, I see many people adding things like RewriteEngine On ... Sometimes these people don't have mod_rewrite compiled into the server, and then instead of getting a useful error message about the directive not being understood, the server silently ignores them. In other words, we are setting a bad example by liberally using and we are confusing users. Joshua
Re: [PATCH] Apache2 httpd.conf
> Cliff Woolley wrote: >> >> On Fri, 21 Jun 2002, Bill Stoddard wrote: >> >> >> can we apply this simple patch so that we dont have to always >> >> uncomment >> >> 12 lines for getting mod_info / mod_status working? >> > >> > +1 >> >> -0.5 Our default config has always taken a minimalist policy, I believe. the patch doesnt enable the modules, just only it's easier to enable them with only removing one # at the load command...; also I'm more thinking of disabling the modules after I have already used them; and if I then comment the load command I must also comment six config lines per module because the config isnt blocked with IfModule... > Having it loaded and having it active and enabled are, IMO, 2 > separate entities. I would prefer not having a generic build which > happens to include these modules be active by default, so I'm like > -0.75 about this :) why should somebody load the modules and waste memory if he doesnt use them?? And again: the patch makes it erasier to enable / disable the modules, it does _NOT_ enable them by default. Guenter.
Re: [PATCH] Apache2 httpd.conf
Bill Stoddard wrote: > > Playing devil's advocate :-) mod_status and mod_info should NOT be loaded by >default. > Agreed! Wouldn't this change set things up so that if someone does a compile with mod_status and mod_info included, the resultant config file would make them active? That was my understanding. If not, then, well... (in my best Emily Latella voice)... "never mind" :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: [PATCH] Apache2 httpd.conf
> > > > On Fri, 21 Jun 2002, Bill Stoddard wrote: > > > > >> can we apply this simple patch so that we dont have to always uncomment > > >> 12 lines for getting mod_info / mod_status working? > > > > > > +1 > > > > -0.5 Our default config has always taken a minimalist policy, I believe. > > > > Having it loaded and having it active and enabled are, IMO, 2 > separate entities. I would prefer not having a generic build which > happens to include these modules be active by default, so I'm like > -0.75 about this :) Playing devil's advocate :-) mod_status and mod_info should NOT be loaded by default. Bill
Re: [PATCH] Apache2 httpd.conf
> On Fri, 21 Jun 2002, Bill Stoddard wrote: > > >> can we apply this simple patch so that we dont have to always uncomment > >> 12 lines for getting mod_info / mod_status working? > > > > +1 > > -0.5 Our default config has always taken a minimalist policy, I believe. > > --Cliff > Is there a reason that we should not completely remove the commented out mod_status and mod_info config directives from the default config then? I don't see that the proposed patch adds any complexity what so ever and it makes it a bit easier to get mod_info and mod_status enabled. Bill
Re: [PATCH] Apache2 httpd.conf
Cliff Woolley wrote: > > On Fri, 21 Jun 2002, Bill Stoddard wrote: > > >> can we apply this simple patch so that we dont have to always uncomment > >> 12 lines for getting mod_info / mod_status working? > > > > +1 > > -0.5 Our default config has always taken a minimalist policy, I believe. > Having it loaded and having it active and enabled are, IMO, 2 separate entities. I would prefer not having a generic build which happens to include these modules be active by default, so I'm like -0.75 about this :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: [PATCH] Apache2 httpd.conf
On Fri, 21 Jun 2002, Bill Stoddard wrote: >> can we apply this simple patch so that we dont have to always uncomment >> 12 lines for getting mod_info / mod_status working? > > +1 -0.5 Our default config has always taken a minimalist policy, I believe. --Cliff
Re: [PATCH] Apache2 httpd.conf /2
My vote is to leave this out of the config file but certainly put it in the doc.
Bill
Hi,
I've been asked now a couple of times for a configuration sample for mod_deflate; and
since mod_deflate is now a 'normal' module and no more experimental I think there
should
be a sample in the httpd.conf; if you dont think so at least a sample as below should
appear in the docs to mod_deflate...
Ian, do you think the sample is ok so?
--- httpd-win.conf.orig Fri Jun 21 14:26:30 2002
+++ httpd-win.conf Fri Jun 21 14:44:40 2002
@@ -169,6 +169,7 @@
LoadModule userdir_module modules/mod_userdir.so
#LoadModule usertrack_module modules/mod_usertrack.so
#LoadModule vhost_alias_module modules/mod_vhost_alias.so
+#LoadModule deflate_module modules/mod_deflate.so
#LoadModule ssl_module modules/mod_ssl.so
#
@@ -948,3 +949,24 @@
#ErrorLog logs/dummy-host.example.com-error_log
#CustomLog logs/dummy-host.example.com-access_log common
#
+
+#
+# Configuration for mod_deflate
+
+# DeflateFilterNote - Set a note to report on compression ratio
+DeflateFilterNote deflate_ratio
+LogFormat "%h %l %u %t \"%r\" %>s %b mod_deflate: %{deflate_ratio}n pct."
common_with_deflate_info
+CustomLog logs/deflate.log common_with_deflate_info
+# Set the Deflate window size (1-15)
+DeflateWindowSize 10
+# Set the Deflate Memory Level (1-9)
+DeflateMemLevel 6
+# Here is an example of enabling compression for the Apache documentation:
+
+SetEnv gzip-only-text/html 1
+SetOutputFilter DEFLATE
+
+
+# End of mod_deflate.
+
+
--- httpd-nw.conf.orig Fri Jun 21 14:29:15 2002
+++ httpd-nw.conf Fri Jun 21 14:46:07 2002
@@ -139,6 +139,7 @@
#LoadModule unique_id_module modules/uniqueid.nlm
#LoadModule usertrack_module modules/usertrk.nlm
#LoadModule vhost_alias_module modules/vhost.nlm
+#LoadModule deflate_module modules/deflate.nlm
#
# ExtendedStatus controls whether Apache will generate "full" status
@@ -948,3 +949,24 @@
#ErrorLog logs/dummy-host.example.com-error_log
#CustomLog logs/dummy-host.example.com-access_log common
#
+
+#
+# Configuration for mod_deflate
+
+# DeflateFilterNote - Set a note to report on compression ratio
+DeflateFilterNote deflate_ratio
+LogFormat "%h %l %u %t \"%r\" %>s %b mod_deflate: %{deflate_ratio}n pct."
common_with_deflate_info
+CustomLog logs/deflate.log common_with_deflate_info
+# Set the Deflate window size (1-15)
+DeflateWindowSize 10
+# Set the Deflate Memory Level (1-9)
+DeflateMemLevel 6
+# Here is an example of enabling compression for the Apache documentation:
+
+SetEnv gzip-only-text/html 1
+SetOutputFilter DEFLATE
+
+
+# End of mod_deflate.
+
+
Re: [PATCH] Apache2 httpd.conf
+1 - Original Message - From: "Günter Knauf" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 21, 2002 8:48 AM Subject: [PATCH] Apache2 httpd.conf Hi, can we apply this simple patch so that we dont have to always uncomment 12 lines for getting mod_info / mod_status working? thanks! --- httpd-win.conf.orig Thu Jun 13 20:39:04 2002 +++ httpd-win.conf Fri Jun 21 14:26:30 2002 @@ -850,24 +850,28 @@ # Allow server status reports, with the URL of http://servername/server-status # Change the ".@@DomainName@@" to match your domain to enable. # -# -#SetHandler server-status -#Order deny,allow -#Deny from all -#Allow from .@@DomainName@@ -# + + +SetHandler server-status +Order deny,allow +Deny from all +Allow from .@@DomainName@@ + + # # Allow remote server configuration reports, with the URL of # http://servername/server-info (requires that mod_info.c be loaded). # Change the ".your-domain.com" to match your domain to enable. # -# -#SetHandler server-info -#Order deny,allow -#Deny from all -#Allow from .@@DomainName@@ -# + + +SetHandler server-info +Order deny,allow +Deny from all +Allow from .@@DomainName@@ + + # # Proxy Server directives. Uncomment the following lines to --- httpd-std.conf.in.orig Sat Jun 15 09:21:00 2002 +++ httpd-std.conf.in Fri Jun 21 14:25:03 2002 @@ -941,24 +941,28 @@ # Allow server status reports, with the URL of http://servername/server-status # Change the ".your-domain.com" to match your domain to enable. # -# -#SetHandler server-status -#Order deny,allow -#Deny from all -#Allow from .your-domain.com -# + + +SetHandler server-status +Order deny,allow +Deny from all +Allow from .your-domain.com + + # # Allow remote server configuration reports, with the URL of # http://servername/server-info (requires that mod_info.c be loaded). # Change the ".your-domain.com" to match your domain to enable. # -# -#SetHandler server-info -#Order deny,allow -#Deny from all -#Allow from .your-domain.com -# + + +SetHandler server-info +Order deny,allow +Deny from all +Allow from .your-domain.com + + # # Proxy Server directives. Uncomment the following lines to
[PATCH] 1.3 - bad vs overflow
And the 1.3 version...
Index: src/main/http_protocol.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
retrieving revision 1.320
diff -u -r1.320 http_protocol.c
--- src/main/http_protocol.c19 Jun 2002 18:44:25 - 1.320
+++ src/main/http_protocol.c21 Jun 2002 13:42:54 -
@@ -1985,6 +1985,7 @@
else if (lenp) {
const char *pos = lenp;
int conversion_error = 0;
+int ou_flow = 0;
while (ap_isdigit(*pos) || ap_isspace(*pos))
++pos;
@@ -1993,15 +1994,23 @@
char *endstr;
errno = 0;
r->remaining = ap_strtol(lenp, &endstr, 10);
-if (errno || (endstr && *endstr)) {
+if (errno == ERANGE) { /* ap_strtol MUST be ANSI */
+ ou_flow = 1;
+}
+else if (errno || (endstr && *endstr)) {
conversion_error = 1;
}
}
-if (*pos != '\0' || conversion_error) {
+if (*pos != '\0' || conversion_error || ou_flow) {
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
"Invalid Content-Length");
-return HTTP_BAD_REQUEST;
+if (ou_flow) {
+return HTTP_REQUEST_ENTITY_TOO_LARGE;
+}
+else {
+return HTTP_BAD_REQUEST;
+}
}
}
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
[PATCH] 2.0 - bad vs overflow
This seems a bit more accurate to me... Comments?
Index: modules/http/http_protocol.c
===
RCS file: /home/cvs/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.440
diff -u -r1.440 http_protocol.c
--- modules/http/http_protocol.c19 Jun 2002 18:43:28 - 1.440
+++ modules/http/http_protocol.c21 Jun 2002 13:44:28 -
@@ -795,6 +795,7 @@
else if (lenp) {
const char *pos = lenp;
int conversion_error = 0;
+int ou_flow = 0;
/* This ensures that the number can not be negative. */
while (apr_isdigit(*pos) || apr_isspace(*pos)) {
@@ -808,20 +809,29 @@
ctx->state = BODY_LENGTH;
ctx->remaining = strtol(lenp, &endstr, 10);
-if (errno || (endstr && *endstr)) {
+if (errno == ERANGE) { /* depend on ANSI strtol */
+ou_flow = 1;
+}
+else if (errno || (endstr && *endstr)) {
conversion_error = 1;
}
}
-if (*pos != '\0' || conversion_error) {
+if (*pos != '\0' || conversion_error || ou_flow) {
apr_bucket_brigade *bb;
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, f->r,
"Invalid Content-Length");
bb = apr_brigade_create(f->r->pool, f->c->bucket_alloc);
-e = ap_bucket_error_create(HTTP_REQUEST_ENTITY_TOO_LARGE, NULL,
+if (ou_flow) {
+e = ap_bucket_error_create(HTTP_REQUEST_ENTITY_TOO_LARGE, NULL,
f->r->pool, f->c->bucket_alloc);
+}
+else {
+e = ap_bucket_error_create(HTTP_BAD_REQUEST, NULL,
+ f->r->pool, f->c->bucket_alloc);
+}
APR_BRIGADE_INSERT_TAIL(bb, e);
e = apr_bucket_eos_create(f->c->bucket_alloc);
APR_BRIGADE_INSERT_TAIL(bb, e);
@@ -1709,6 +1719,7 @@
else if (lenp) {
const char *pos = lenp;
int conversion_error = 0;
+int ou_flow = 0;
while (apr_isdigit(*pos) || apr_isspace(*pos)) {
++pos;
@@ -1720,15 +1731,23 @@
errno = 0;
r->remaining = strtol(lenp, &endstr, 10);
-if (errno || (endstr && *endstr)) {
+if (errno == ERANGE) { /* depend on ANSI strtol */
+ou_flow = 1;
+}
+else if (errno || (endstr && *endstr)) {
conversion_error = 1;
}
}
-if (*pos != '\0' || conversion_error) {
+if (*pos != '\0' || conversion_error || ou_flow) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
"Invalid Content-Length");
-return HTTP_BAD_REQUEST;
+if (ou_flow) {
+return HTTP_REQUEST_ENTITY_TOO_LARGE;
+}
+else {
+return HTTP_BAD_REQUEST;
+}
}
}
@@ -1738,6 +1757,7 @@
"%s with body is not allowed for %s", r->method, r->uri);
return HTTP_REQUEST_ENTITY_TOO_LARGE;
}
+
#ifdef AP_DEBUG
{
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
[PATCH] Apache2 httpd.conf /2
Hi,
I've been asked now a couple of times for a configuration sample for mod_deflate; and
since mod_deflate is now a 'normal' module and no more experimental I think there
should be a sample in the httpd.conf; if you dont think so at least a sample as below
should appear in the docs to mod_deflate...
Ian, do you think the sample is ok so?
--- httpd-win.conf.orig Fri Jun 21 14:26:30 2002
+++ httpd-win.conf Fri Jun 21 14:44:40 2002
@@ -169,6 +169,7 @@
LoadModule userdir_module modules/mod_userdir.so
#LoadModule usertrack_module modules/mod_usertrack.so
#LoadModule vhost_alias_module modules/mod_vhost_alias.so
+#LoadModule deflate_module modules/mod_deflate.so
#LoadModule ssl_module modules/mod_ssl.so
#
@@ -948,3 +949,24 @@
#ErrorLog logs/dummy-host.example.com-error_log
#CustomLog logs/dummy-host.example.com-access_log common
#
+
+#
+# Configuration for mod_deflate
+
+# DeflateFilterNote - Set a note to report on compression ratio
+DeflateFilterNote deflate_ratio
+LogFormat "%h %l %u %t \"%r\" %>s %b mod_deflate: %{deflate_ratio}n pct."
+common_with_deflate_info
+CustomLog logs/deflate.log common_with_deflate_info
+# Set the Deflate window size (1-15)
+DeflateWindowSize 10
+# Set the Deflate Memory Level (1-9)
+DeflateMemLevel 6
+# Here is an example of enabling compression for the Apache documentation:
+
+SetEnv gzip-only-text/html 1
+SetOutputFilter DEFLATE
+
+
+# End of mod_deflate.
+
+
--- httpd-nw.conf.orig Fri Jun 21 14:29:15 2002
+++ httpd-nw.conf Fri Jun 21 14:46:07 2002
@@ -139,6 +139,7 @@
#LoadModule unique_id_module modules/uniqueid.nlm
#LoadModule usertrack_module modules/usertrk.nlm
#LoadModule vhost_alias_module modules/vhost.nlm
+#LoadModule deflate_module modules/deflate.nlm
#
# ExtendedStatus controls whether Apache will generate "full" status
@@ -948,3 +949,24 @@
#ErrorLog logs/dummy-host.example.com-error_log
#CustomLog logs/dummy-host.example.com-access_log common
#
+
+#
+# Configuration for mod_deflate
+
+# DeflateFilterNote - Set a note to report on compression ratio
+DeflateFilterNote deflate_ratio
+LogFormat "%h %l %u %t \"%r\" %>s %b mod_deflate: %{deflate_ratio}n pct."
+common_with_deflate_info
+CustomLog logs/deflate.log common_with_deflate_info
+# Set the Deflate window size (1-15)
+DeflateWindowSize 10
+# Set the Deflate Memory Level (1-9)
+DeflateMemLevel 6
+# Here is an example of enabling compression for the Apache documentation:
+
+SetEnv gzip-only-text/html 1
+SetOutputFilter DEFLATE
+
+
+# End of mod_deflate.
+
+
httpd-win.conf.patch-deflate
Description: Binary data
httpd-nw.conf.patch-deflate
Description: Binary data
[PATCH] Apache2 httpd.conf
Hi, can we apply this simple patch so that we dont have to always uncomment 12 lines for getting mod_info / mod_status working? thanks! --- httpd-win.conf.orig Thu Jun 13 20:39:04 2002 +++ httpd-win.conf Fri Jun 21 14:26:30 2002 @@ -850,24 +850,28 @@ # Allow server status reports, with the URL of http://servername/server-status # Change the ".@@DomainName@@" to match your domain to enable. # -# -#SetHandler server-status -#Order deny,allow -#Deny from all -#Allow from .@@DomainName@@ -# + + +SetHandler server-status +Order deny,allow +Deny from all +Allow from .@@DomainName@@ + + # # Allow remote server configuration reports, with the URL of # http://servername/server-info (requires that mod_info.c be loaded). # Change the ".your-domain.com" to match your domain to enable. # -# -#SetHandler server-info -#Order deny,allow -#Deny from all -#Allow from .@@DomainName@@ -# + + +SetHandler server-info +Order deny,allow +Deny from all +Allow from .@@DomainName@@ + + # # Proxy Server directives. Uncomment the following lines to --- httpd-std.conf.in.orig Sat Jun 15 09:21:00 2002 +++ httpd-std.conf.in Fri Jun 21 14:25:03 2002 @@ -941,24 +941,28 @@ # Allow server status reports, with the URL of http://servername/server-status # Change the ".your-domain.com" to match your domain to enable. # -# -#SetHandler server-status -#Order deny,allow -#Deny from all -#Allow from .your-domain.com -# + + +SetHandler server-status +Order deny,allow +Deny from all +Allow from .your-domain.com + + # # Allow remote server configuration reports, with the URL of # http://servername/server-info (requires that mod_info.c be loaded). # Change the ".your-domain.com" to match your domain to enable. # -# -#SetHandler server-info -#Order deny,allow -#Deny from all -#Allow from .your-domain.com -# + + +SetHandler server-info +Order deny,allow +Deny from all +Allow from .your-domain.com + + # # Proxy Server directives. Uncomment the following lines to httpd-win-nw.conf.patch Description: Binary data httpd-std.conf.in.patch Description: Binary data
Re: Content-Length specifics
Jim Jagielski wrote: > > Yes, it still works, though mostly it's because we '%ld' the value > in the table. ;) I was just walking through what could happen if, > in some way, the value in the table was something like "123 " or so. > That does not look possible, but if it *does* happen, then our current > code will see that as a bad request (the (endptr && *endptr) test). > Not a problem, but a point to keep in mind. > That's both 1.3 and 2.0, btw. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: Content-Length specifics
Cliff Woolley wrote: > > On Thu, 20 Jun 2002, Justin Erenkrantz wrote: > > > I believe so. Our current implementation supports it. -- justin > > Does 1.3's now that we've changed it? > Yes, it still works, though mostly it's because we '%ld' the value in the table. ;) I was just walking through what could happen if, in some way, the value in the table was something like "123 " or so. That does not look possible, but if it *does* happen, then our current code will see that as a bad request (the (endptr && *endptr) test). Not a problem, but a point to keep in mind. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: [SECURITY] Remote exploit for 32-bit Apache HTTP Server known
On Fri, 21 Jun 2002 [EMAIL PROTECTED] wrote: > Concerning this vulnerability: is safe to assume that a patched > reverse proxy will protect a vulnerable back end server from such > malicious requests? I think that even unpatched Apache will protect backend - as all modules that have deal with clients body mod_proxy does not support client's chunked request. Of course, unpatched frontend is still vulnerable. Igor Sysoev http://sysoev.ru
Re: [SECURITY] Remote exploit for 32-bit Apache HTTP Server known
[EMAIL PROTECTED] wrote: > Concerning this vulnerability: is safe to assume that a patched > reverse proxy will protect a vulnerable back end server from such > malicious requests? I would imagine so, yes. Regards, Graham -- - [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
Re: [SECURITY] Remote exploit for 32-bit Apache HTTP Server known
Concerning this vulnerability: is safe to assume that a patched reverse proxy will protect a vulnerable back end server from such malicious requests? cu - Harry > "jwoolley" == jwoolley <[EMAIL PROTECTED]> writes: jwoolley> [[ Note: this issue affects both 32-bit and 64-bit jwoolley> platforms; the subject of this message emphasizes 32-bit jwoolley> platforms since that is the most important information jwoolley> not announced in our previous advisory. ]] jwoolley> SUPERSEDES: jwoolley> http://httpd.apache.org/info/security_bulletin_20020617.txt jwoolley> Date: June 20, 2002 Product: Apache Web Server Versions: jwoolley> Apache 1.3 all versions including 1.3.24; Apache 2.0 all jwoolley> versions up to 2.0.36; Apache 1.2 all versions. jwoolley> CAN-2002-0392 (mitre.org) [CERT VU#944335] jwoolley> -- jwoolley> UPDATED ADVISORY jwoolley> -- jwoolley> Introduction: jwoolley> While testing for Oracle vulnerabilities, Mark jwoolley> Litchfield discovered a denial of service attack for jwoolley> Apache on Windows. Investigation by the Apache Software jwoolley> Foundation showed that this issue has a wider scope, jwoolley> which on some platforms results in a denial of service jwoolley> vulnerability, while on some other platforms presents a jwoolley> potential remote exploit vulnerability. jwoolley> This follow-up to our earlier advisory is to warn of jwoolley> known-exploitable conditions related to this jwoolley> vulnerability on both 64-bit platforms and 32-bit jwoolley> platforms alike. Though we previously reported that jwoolley> 32-bit platforms were not remotely exploitable, it has jwoolley> since been proven by Gobbles that certain conditions jwoolley> allowing exploitation do exist. jwoolley> Successful exploitation of this vulnerability can lead jwoolley> to the execution of arbitrary code on the server with jwoolley> the permissions of the web server child process. This jwoolley> can facilitate the further exploitation of jwoolley> vulnerabilities unrelated to Apache on the local system, jwoolley> potentially allowing the intruder root access. jwoolley> Note that early patches for this issue released by ISS jwoolley> and others do not address its full scope. jwoolley> Due to the existence of exploits circulating in the wild jwoolley> for some platforms, the risk is considered high. jwoolley> The Apache Software Foundation has released versions jwoolley> 1.3.26 and 2.0.39 that address and fix this issue, and jwoolley> all users are urged to upgrade immediately; updates can jwoolley> be downloaded from http://httpd.apache.org/ . jwoolley> As a reminder, we respectfully request that anyone who jwoolley> finds a potential vulnerability in our software reports jwoolley> it to [EMAIL PROTECTED] jwoolley> -- jwoolley> The full text of this advisory including additional jwoolley> details is available at jwoolley> http://httpd.apache.org/info/security_bulletin_20020620.txt jwoolley> .
Re: Content-Length specifics
On Thu, 20 Jun 2002, Jim Jagielski wrote: > Is whitespace allowed after the value set in Content-Length? eg: > >Content-Length: 12344 \r\n > ^^ We've allways followed the IETF dogma: Be strict in what you send, but liberal in what you accept. Looking at the BNF in 2616 - it's a valid header. Looking at the definition of the length itself; not too clear it is wrong - in fact - this is not too well described. Dw
Re: [PATCH httpd 1.2] chunk size overflow
William A. Rowe, Jr. wrote: >> > What about the proxy? >> > >> >> Not really a problem with 1.2, or other non HTTP/1.1 proxies I think :) > > > Not a problem, IIRC, until we introduced 1.3.24 with the HTTP/1.1 proxy. As far as I remember, proxy uses the existing chunking functions in http_protocol.c to do chunking. Regards, Graham -- - [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
