Joshua Slive wrote:
notedirectiveScriptAlias/directive is used to
strongboth/strong map a URL to a directory strongand/strong
mark requests for that URL as pointing to CGI scripts. It should not
be used for directories that are already accessible from the web
because they are under the
Boyle Owen wrote:
- You're right that since apache can't see the host header, it uses the cert
from the default VH to establish the SSL session. Thereafter, it *can* see the
host header and so can route the requests successfully. This give a lot of
people the illusion that SSL-NBVH is
Boyle Owen wrote:
-Original Message-
From: David Burry [mailto:[EMAIL PROTECTED]
We use a wildcard cert to overcome this situation...
How did you get your wildcard cert? Did you buy it? Apparently, the cert
sellers (Thwate, Versign etc.) are not too keen on selling wildcards
Dependancy on third party modules still prevents us from upgrading from
1.3 to 2.0 or at least makes the the drawbacks of upgrading more
than the benefits That's the main holdup for us.
For instance, mod_perl (and a few custom scripts that use the API
extensively), mod_php (all those
Has anyone checked this out yet?
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0492
It was reported in cnet news a month or two ago, and my SOX security
guys at work have been bugging me about it... I need to tell them
either it's a false alarm or it will be fixed soon.
Any current
Whether labeled experimental or not, it's always been very confusing
to me that the release (stable) branch has modules in it that
developers know don't work at all and therefore should not ever be
attempted to be used by any ordinary user in any way whatsoever...
Therefore I agree, stable
Perhaps we could use a new module that allows efficient on-the-fly
config parameter changes without restarting any processes? Kind of like
a config server that you connect to and issue commands that add and
remove apache directives, at least most of them if not all of them.
There have been a
I agree entirely, as the documentation says, rewrite rules
are voodoo and often very hard to understand what's going
on and why a given ruleset isn't working as expected (which
is not the same as an error in the errorlog, more of a user
error). The inability to trace through what it's doing in
Since there seems to be some disagreement on this, and the RFC doesn't
really specify which it is but instead makes a point of leaving it open
for discussion, and there are many other popular servers out there that
behave differently than apache and therefore some people may come to
expect (nay
- Original Message -
From: Graham Leggett
Martin Kutschker wrote:
Removing the server header won't hurt.
Removing the server header is a protocol viloation, and serves no purpose.
How is it a protocol violation? I can't find anywhere in the HTTP 1.1
protocol where it says the
I don't see a good reason not to have a ServerTokens None option... All
the ServerTokens options that hide version numbers are security by
obscurity anyway So it's not really anything new, just expanding
something that already exists to have a more complete compliment of
similar options.
-0800, David Burry wrote:
These are neat ideas. At a few companies I've worked for we already do
similar things but we have scripts that generate the httpd.conf files
and distribute them out to the web servers and gracefully restart.
Adding a new web server machine to the mix is as simple
These are neat ideas. At a few companies I've worked for we already do
similar things but we have scripts that generate the httpd.conf files
and distribute them out to the web servers and gracefully restart.
Adding a new web server machine to the mix is as simple as adding the
host name to the
are we talking about removing modules entirely, or just modifying what's
enabled by default?
Dave
- Original Message -
From: Justin Erenkrantz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, March 09, 2003 8:39 PM
Subject: Re: Proposal: Remove mod_imap from default list
--On
2.1 was started so that 2.0 can remain stable from here on out instead of
changing the 2.0 API with every minor release, requiring everyone to re-port
their modules with every minor 2.0 release so the fact that 2.1 exists
is a very good sign for 2.0!
Dave
- Original Message -
From:
I am running the server/client on the
same machine.
You will not get reliable results by doing this.
Can you elaborate why? Plus we were forced to do this,
but would like to avoid in the future if it really affects
our results.
Because the client will contend very heavily with the
On our systems we just rename that alteoncheck.txt file to
alteoncheck_DOWN.txt when we're going to bring a server down (causing a
404 error for the health check, which stops all new requests), it
effectively does the same thing you describe without the hassle of writing a
handler. And yes it is
I've seen the exact same problem, and diagnosed it as the same issue. It
would be very nice to have the default apache installation handle this
properly, to prevent the dumb we-think-we're-smarter-than-you browsers from
renaming files... if not by monkeying with the mime types file for pureness
The same effect is already possible by configuring your proxying machine to
stop forwarding new requests to that box first Of course, it's possible
that different people manage the proxying service vs the back end apache
services, so I can see how it can be desireable to have this feature in
PROTECTED]
Sent: Tuesday, February 04, 2003 12:25 PM
Subject: Re: Graceful shutdown in 2.0
David Burry wrote:
The same effect is already possible by configuring your proxying machine
to
stop forwarding new requests to that box first
Yep, that's the idea. In the scenario I'm interested
Random thoughts:
- Did the content have short expiration times (or recent change dates
which
would result in the cache making agressive expiration estimates). That
could
churn the cache.
No. files literally never change, when updates appear they are always new
files, web pages just point to
- Original Message -
From: Brian Pane [EMAIL PROTECTED]
Sent: Thursday, January 02, 2003 2:19 PM
For large files, I'd anticipate that mod_cache wouldn't provide much
benefit
at all. If you characterize the cost of delivering a file as
time_to_stat_and_open_and_close +
]
Sent: Thursday, January 02, 2003 9:43 PM
Subject: Re: mod_mem_cache bad for large/busy files (Was: [PATCH] removesome
mutex locks in the worker MPM)
On Thu, 2003-01-02 at 21:21, David Burry wrote:
- Original Message -
From: Brian Pane [EMAIL PROTECTED]
Sent: Thursday, January 02
Apache 2.0.43, Solaris 8, Sun E220R, 4 gig memory, gig ethernet. We tried
both Sun forte and gcc compilers. The problem was mod_mem_cache was just
way too resource intensive when pounding on a machine that hard, trying to
see if everything would fit into the cache... cpu/mutexes were very high,
- Original Message -
From: David Burry [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, December 31, 2002 5:54 PM
Subject: Re: [PATCH] remove some mutex locks in the worker MPM
Ohh this sounds like an awesome optimization... I noticed mutex
contentions
were extremely high on a very high traffic
What does everyone think about releasing 2.0.44 soon? My company kind of
needs the logio fixes but we're hesitant to run our own special patched
version of 2.0.43 when we have so much riding on this project...
Dave
Recently there has been a little discussion about an API in apache for
controlling starts, stops, restarts, etc...
I have an idea that may help me solve a problem I've been having. The
problem is in limiting the number of processes that will run on a machine to
somewhere below where the machine
shutdown and restart).
Of course one could also argue for not just a put but also for a 'get'
interface in context :-)
Dw
On Mon, 4 Nov 2002, David Burry wrote:
Recently there has been a little discussion about an API in apache for
controlling starts, stops, restarts, etc...
I have
certainly do it more generically, I just
haven't had the need. You might check mod_backhand.]
Later,
scott
On Mon, 4 Nov 2002, David Burry wrote:
I realize that allowing _everything_ to be dynamically configured via
SNMP (or signal or something) would probably be too substantial of an
API change
Awesome script... I hadn't thought of doing it this way, this is better
than what I was thinking.. it seems to address everyone's concerns too in
the best way that's still within our resources.
Dave
- Original Message -
From: Justin Erenkrantz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Excellent little utility... however closer network-wise is often
significantly different than closer geographically, for instance California
is likely a lot closer to Peru than Chile is (as an extreme example), if you
go by the packets fly instead of by the crow flies... Also when a closer
Is it possible to get some of the fixes to mod_logio committed? Wouldn't
everyone agree that the current logging of the outgoing bytes is incorrect
behavior? Currently it logs the full file size (plus headers) even if it
gets cut off in the middle, instead of the actual number of bytes sent.
- Original Message -
From: Bojan Smojver [EMAIL PROTECTED]
On Fri, 2002-10-25 at 03:31, David Burry wrote:
Is it possible to get some of the fixes to mod_logio committed?
Wouldn't
everyone agree that the current logging of the outgoing bytes is
incorrect
behavior? Currently
of our statistics
(duplicated nearby days' data with similar overall throughputs) due to us not catching
the problem with Apache 2.0 soon enough...
Dave
At 09:15 AM 10/25/2002 +1000, Bojan Smojver wrote:
On Fri, 2002-10-25 at 07:42, David Burry wrote:
I see.. ok, I'll keep waiting patiently
At 09:38 PM 10/24/2002 -0400, Glenn wrote:
Have you looked at the %...X directive in Apache2?
That's an interesting idea I hadn't thought of... it doesn't solve the chargeback
issue but it's worth investigating for detecting successful downloads...
Dave
At 08:45 PM 10/24/2002 -0500, William A. Rowe, Jr. wrote:
At 08:40 PM 10/24/2002, Bojan Smojver wrote:
Quoting David Burry [EMAIL PROTECTED]:
Excellent! I will perform some tests with that when I get a chance! You
managed to get it working without breaking pipelining even? That's awesome
I know that I'm ultimately wanting to log bytes per request pretty
accurately to add up and tell if the whole file was transferred or not even
if it was broken up into several byte range requests. I have given up on
the possibility of this happening in 2.0 for a long time to come due to the
- Original Message -
From: Thomas Eibner [EMAIL PROTECTED]
On Wed, Oct 16, 2002 at 11:20:07AM -0400, Bill Stoddard wrote:
Hi,
Why url finishing by / are not cacheable ?
muddled thinking ? :-) I was unsure how to handle caching default index
pages but I see no reason why we
, David Burry wrote:
Has anyone worked on an Apache test suite? You know, like how many
things
have a make test that runs all sorts of tests... or perhaps a separate
package that runs tests... I might be interested in starting one but
would
rather build upon other's work if some of it has
Has anyone worked on an Apache test suite? You know, like how many things
have a make test that runs all sorts of tests... or perhaps a separate
package that runs tests... I might be interested in starting one but would
rather build upon other's work if some of it has already been done...
Dave
:
./configure --prefix=/usr/local/apache_2.0.43+logio --enable-logio --enable-
usertrack --enable-file-cache --enable-cache --enable-mem-cache --enable-sta
tic-support --disable-cgid --disable-cgi --enable-rewrite --with-mpm=worker
--disable-userdir
Dave
- Original Message -
From: David Burry
Being off by a little is better than being off by the whole thing... My
tests show that was Apache 1.3 behavior... At least that way the value is
close, so if you're charging for bandwidth you're not overcharging so much,
and you can still tell if the whole file got there or not.
Dave
-
The documentation for Apache 2.0.43 for mod_log_config states:
%...b: Bytes sent, excluding HTTP headers. In CLF format i.e. a '-' rather than a 0
when no bytes are sent.
However, in testing I clearly see it's logging the number of bytes _requested_ (that
is, that apache intended to send)!!!
I agree that mod_gzip does a lot better job as far as compression goes, and
it doesn't even use more cpu likely.
However, it's still important to remove HTML and JavaScript comments
sometimes for security reasons, but I suspect this could probably be better
done as part of the publishing
This may be confusing because people may begin to expect it to do the substitution at
request time in certain cases instead of only at server startup time Admittedly
that would be almost like turning every directive into mod_rewrite, but... an env var
is an env var, many things are
By the way, I love the idea of backporting the Apache 2.0
ForceLanguagePriority into Apache 1.3... This directive completely solves a
looot of problems I've been having with stupid non-standards-conformant IE
and content negotation. Many thanks to whoever posted the patch. If only
it were
You may want to try actually grabbing a couple-byte monitor page in your case from the
load balancers and parse it and look for a special string inside it, that's what we do
and that works well. This method not only tests if a connection is being opened, but
more thoroughly tests server
What about using something else external to apache to detect output under
netware? Is it possible to pipe the output to something else that detects
if there is any, and holds the window open only if there is? Wouldn't that
solve the problem in a more consistent way than altering the return
While we are debating the best way to accomplish this Content-Length fix for the next
release, I kind of need to have it working for me right now in the current released
version. Therefore I've implemented this partial fix against 1.3.26 on my system:
root@nueva[391] pwd
I have a situation where I have an external-facing apache server proxying to another
apache server inside a firewall. I've updated the proxying one to Apache 1.3.26 so
that it won't get hacked due to the chunked encoding bug, but I'm not able to upgrade
the other one behind the firewall for
Hi!
I'm having a problem since upgrading from Apache 1.3.23 to 1.3.26. It appears that
the Content-Length header field is much more strict in what it will accept from http
clients than it was before, and this is causing me biiig problems.
A certain http client (which shall remain nameless
51 matches
Mail list logo
