On the mod_perl list it has been considered a DOS attack, and not an
exploit.
It's also only in Apache::PerlRun - so doesn't affect users using the more
popular Apache::Registry (was fixed mid-2000). Nor does it affect users
using pure-handlers.
I'd also point out that the release also fixes
Package: apache
Version: 1.3.31-5
Severity: wishlist
Could this be included with the debian apache package?
http://sysoev.ru/en/
It's an alternative to mod_gzip, which seems to be much more mature - it
also links with zlib rather than including it's own version.
Carl
> Can you give us the patch directly since you have it working?
I'm actually a little concerned that it might break something else!
I've been working with a clean (non Debian) apache source, so it's really an
upstream problem. What is their policy regarding regular bugs in 1.3? Are they
s
I've managed to track down why QUERY_STRING works and PATH_INFO doesn't.
In src/modules/standard/mod_include.c around line 2181 mod_include fixes up
the QUERY_STRING. If I add similar code to fixup PATH_INFO ie:
if (r->path_info) {
ap_table_setn(r->subprocess_env, "PATH_INFO", r->path_i
Hi,
The "debian way" is the standard Apache way - check out the documentation on
the Apache web site - specifically here's the URL for the virtual host docs.
http://httpd.apache.org/docs-2.0/vhosts/
Carl
PS This is the apache-development mailing list for discussing apache
development. Y
> I wonder if we should reassign this bug to all the MTA since
> some of the
> ship newaliases in /usr/bin and others in /usr/sbin (that
> apache uses).
You don't need to run newaliases with exim - which is Debian's recommended MTA.
How do other packages handle adding email aliases? Might
> No, they shouldn't! PATH_INFO '... holds the additional path
> information
> that remains after the URI has been translated into a file path.' [1]
> So, if your URI is 'http://site/test2.html'
>
> 1) URI to file translation:
>
> http://site/test2.html => {DOCUMENT ROOT}/test2.html
>
Package: apache
Version: 1.3.29.0.2-4
Severity: normal
test.html
---
test2.html -
-
Requesting http://site/test.html/path?query gives me:
path query
Requesting http://site/test2.html gives me:
(none) query
They should ma
Hi Joe,
That's the correct documented behaviour for Apache - once you define
VirtualHosts, the first VirtualHost becomes the default site. Just add a blank
VirtualHost before the others you've designed, by default it will inherit all
it's settings from your "main" Apache config.
Carl
PS
> While you're at it ;-) please also skip files matching '*.dpkg-*'.
That a good point - dpkg/apt etc will be dropping conffiles into
/etc/apache/conf.d and -dpkg- files may be left behind due to this.
Carl
GMG Regional Digital is
Similar to my apache 1.3 bug - wouldn't it be better to fix apxs to generate
the .load file needed to make it work the new "Debian" way?
Carl
GMG Regional Digital is part of the Guardian Media Group plc.
CONFIDENTIALITY NOTICE. The
> If -4 will go in without any problem, -5 will contain a major
> change from
> the actual old config layout to the apache2 config layout,
> that will make
> easier for everyone to transit from one package to another
> and vice versa
> without too much headache.
is -5 for sarge+1 then?
Carl-
> The security benefits of the experimental perchild module can be
> approximated by running multiple instances of apache2,
you can't run two instances of apache on the same server using the same port
as it's always been possible to run multiple copies of apache as different
users, being able t
severity 227997 important
tags 227997 upstream
tags 227997 pending
stop
quit
Fabio:
> it seems to me that this option can be used only when mod_usertrack is
> statically compiled into apache (and in our case it is not
> since we make use of DSO).
"Compiled in" is poor choice of wording in the d
Package: apache-dev
Version: 1.3.29.0.1-3
Severity: minor
when installing 3rd party modules using apxs:
* no .info file is created in /usr/lib/apache breaking module-config
* a configuration line is added directly to the apache config, rather
than using modules-config to enable the module
>
> Two separate apache installs both exhibit the same problem -
> one of which is a fairly clean re-install I did recently for
> testing purposes. I assumed it would be easy to reproduce :-)
>
Just re-installed apache from scrach again, and apache exhibits the same
problem - wierd!
Carl
Package: apache-common
Version: 1.3.29.0.1-3
Severity: grave
Enabling mod_usertrack causes apache to Segfault.
Carl
> Recently sarge has received a new version of perl but apache
> and mod-perl
> packages in sarge are old. Until the sid packages will not enter sarge
> there is no way for us to "fix" this problem since it is already fixed
> since a while in sid. We have no control over the package
> flow from
18 matches
Mail list logo
