--On Monday, October 25, 2004 9:04 PM -0700 Roy T. Fielding
[EMAIL PROTECTED] wrote:
This is not an error that the server admin can solve -- it is normal
life on the Internet. We really shouldn't be logging it except when
on DEBUG level.
+1. Info loglevel is way way too high for realistic
--On Friday, October 15, 2004 10:48 AM +0200 Rüdiger Plüm
[EMAIL PROTECTED] wrote:
please find attached a new more general approch to prevent cookies from
being stored in the cache.
As proposed by Justin I replaced my original CacheStoreCookies directive
with the more
general CacheIgnoreHeaders
--On Tuesday, October 12, 2004 4:17 PM +0100 Joe Orton [EMAIL PROTECTED]
wrote:
OK sure, but the point you have to argue is why it's useful to support
this feature *in httpd*. N million 1.3 users live without it. I'm
Agreed. +1 for making it simpler and avoiding the memory hogging. My only
--On Saturday, October 9, 2004 10:54 AM +0100 Joe Orton [EMAIL PROTECTED]
wrote:
It's apparently an issue when you have zlib 1.2.1 installed somewhere,
since in that version zutil.h is considered an internal header and is
not installed by make install:
--On Saturday, October 9, 2004 1:44 AM +0200 Andreas Steinmetz [EMAIL PROTECTED]
wrote:
htcacheclean, take two:
Code cleanups, more apr style coding, presumably feature complete, now
built against apache 2.1 cvs. Needs further testing and especially
niceness tuning. See code below. Comments
--On Friday, October 8, 2004 3:59 PM +0100 Joe Orton [EMAIL PROTECTED] wrote:
zutil.h isn't really needed at all; in fact whole the gzip header could
be in an immortal bucket, much less overhead than jumping through the
psprintf code. Try this?
I think we tried to hard-code OS_CODE to 0x03
--On Thursday, October 7, 2004 9:08 AM -0600 Jean-Jacques Clar
[EMAIL PROTECTED] wrote:
All the directives for mod_mem_cache are preceded with an M.
The ones for mod_cache are starting with a c
Should all the disk_cache directives be preceded with a D for
consistency and clarity?
I know it is
--On Thursday, October 7, 2004 7:21 PM +0200 Andreas Steinmetz [EMAIL PROTECTED]
wrote:
Not nice, IMHO. One major problem that prevents the use of apache 2.x for me
is the fact that the cache size cannot be constrained. A cache that can grow
without constraint can't be used on production
--On Thursday, October 7, 2004 12:13 PM -0600 Jean-Jacques Clar
[EMAIL PROTECTED] wrote:
I won't probably agree if we use 'Waboozle', and I suggest that the
description
should with the name of the module like MemCache* and DiskCache* to
make it easier for related directives to be grouped
--On Tuesday, October 5, 2004 10:56 AM +0200 jean-frederic clere
[EMAIL PROTECTED] wrote:
I have now moved all the logic to apr-util. Find enclosed the new patch.
To get it working checkout apr-iconv in srclib and add
--with-iconv=`pwd`/srclib/apr-iconv.
More comments?
Besides the fact that this
--On Monday, October 4, 2004 6:05 PM -0500 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
At 12:00 PM 10/4/2004, Jean-Frederic wrote:
I have prepared a patch to use apr-iconv instead GNU or system iconv.
I'm not hearing alot of interest in maintaining apr-iconv, and
instead perhaps using the BSD
--On Wednesday, September 29, 2004 3:39 PM +0100 Joe Orton
[EMAIL PROTECTED] wrote:
OK, the difference is in the handling of an empty Content-Length header.
The glibc strtoll does not return an error for an empty string, as C99
requires, and so ap_http_filter treats it exactly as Content-Length:
--On Wednesday, September 29, 2004 10:26 AM +0100 Joe Orton
[EMAIL PROTECTED] wrote:
Yup, the t_cmp arguments were flipped a while back.
FWIW, I think whomever flipped the t_cmp arguments but didn't flip the
included test cases at the same time needs a stern talking to. I spent
over an hour
--On Thursday, September 30, 2004 2:54 PM + [EMAIL PROTECTED] wrote:
geoff 2004/09/30 07:54:40
Modified:perl-framework/t/apache acceptpathinfo.t chunkinput.t
errordoc.t getfile.t limits.t options.t
perl-framework/t/filter input_body.t
--On Tuesday, September 28, 2004 5:28 PM +0200 Rüdiger Plüm
[EMAIL PROTECTED] wrote:
starting with Apache 2.0.50 I tried to use mod_cache / mod_disk_cache to
cache
responses from a Tomcat in the backend on the front web server. Several bugs
(most in mod_disk_cache) prevented me from doing so in
--On Tuesday, September 28, 2004 6:31 PM -0500 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
At the same time, there is ***massive*** progress on mod_cache! If the
mod_cache folks think we are ready to roll (and they are getting close)
then another release for all these 'experimental'
--On Thursday, September 23, 2004 12:43 PM +0100 Nick Kew [EMAIL PROTECTED]
wrote:
Basically it does the lookup/dispatch once per filter in the filterchain
per request. It checks that filter's providers until it finds a match.
So for anything you could do with an [Add|Set]OutputFilter[ByType]
--On Friday, September 24, 2004 11:39 AM -0400 Bill Stoddard
[EMAIL PROTECTED] wrote:
So we're missing all the code to handle RFC 2616 section 13.3. We're not
violating the RFC but our cache is sure not as efficient as possible.
Put it this way: we were violating the RFC because our Expires
--On Friday, September 24, 2004 11:25 AM -0700 Justin Erenkrantz
[EMAIL PROTECTED] wrote:
caching-proxied-conditional requests. My preliminary thought is:
1) If cache_select_url() determines the cached response is out-of-date,
it can then add the 'If-None-Match' header (and any other headers
--On Thursday, September 23, 2004 5:38 PM +0200 Graham Leggett
[EMAIL PROTECTED] wrote:
At the same time I (and others) have been criticised in the past for trying
to propose patches that do style changes or that correct whitespace.
What is the official policy on this?
I am quite happy to do as
--On Thursday, September 23, 2004 2:55 PM -0400 Bill Stoddard
[EMAIL PROTECTED] wrote:
This little gem causes a regression. Because cache-handle is left NULL,
we never cleanup stale entries in the cache (in cache_save_filter). Once
CacheMaxExpires hits, the stale entry will never be garbage
--On Thursday, September 23, 2004 8:17 PM -0400 Bill Stoddard
[EMAIL PROTECTED] wrote:
Justin Erenkrantz wrote:
This little gem causes a regression. Because cache-handle is left NULL,
we never cleanup stale entries in the cache (in cache_save_filter). Once
CacheMaxExpires hits, the stale entry
--On Wednesday, September 22, 2004 5:01 PM +0100 Nick Kew [EMAIL PROTECTED]
wrote:
I've said it before and I'll say it again: AddOutputFilterByType is
fundamentally unsatisfactory. This confusion is an effect, not cause.
Suffice to say, I disagree.
* Configuration is inconsistent with other
--On Wednesday, September 22, 2004 6:17 PM +0100 Nick Kew
[EMAIL PROTECTED] wrote:
It seems to me heavily counterintuitive that mixing ByType directives
with anything else means that the ByType filters *always* come last.
And that Remove won't affect them, but will affect others.
I think we
--On Wednesday, September 22, 2004 5:13 PM +0100 Nick Kew
[EMAIL PROTECTED] wrote:
*** A few issues with util_filter in 2.0:
ap_filter_type
==
Making this an enum and then using values like AP_FTYPE_[anything] + 5
(as is done in, for example, mod_ssl) makes no sense. An int with
a
--On Monday, September 20, 2004 12:12 PM + [EMAIL PROTECTED] wrote:
jorton 2004/09/20 05:12:01
Modified:.configure.in
Log:
* configure.in: Ensure that $CC and $CPP are correctly passed through
to the pcre configure script if config caching is disabled (the
autoconf
--On Tuesday, September 21, 2004 3:48 PM -0700 Michael Corcoran
[EMAIL PROTECTED] wrote:
I've been trying to find a solution to a problem that mod_cache has with
handling Etag's properly. I'm working with Apache 2.0.51. Below is a
diff to ./server/util_script.c that seems to fix the problem...
--On Tuesday, September 21, 2004 4:52 PM -0700 Michael Corcoran
[EMAIL PROTECTED] wrote:
On Solaris/Intel, rotatelogs will always crash right after it is
spawned. This only happens on the Solaris/Intel platform. It works
fine on Solaris/SPARC, and on Linux, etc. But for some reason, the code
--On Tuesday, September 21, 2004 9:05 PM +0100 Joe Orton [EMAIL PROTECTED]
wrote:
I think just testing for $cache_file = /dev/null is simplest. That
still fixes my problem and seems to work OK with a cache file specified
too. I've committed that, let's see what breaks now ;)
Thanks!
--On Thursday, September 16, 2004 5:11 PM +0100 Joe Orton [EMAIL PROTECTED]
wrote:
But ap_add_output_filters_by_type() explicitly does nothing for a
proxied request. Anyone know why? AddOutputFilterByType DEFLATE
text/plain text/html seems to work as expected here for a forward proxy
with this
--On Friday, September 17, 2004 1:07 PM -0400 Garrett Rooney
[EMAIL PROTECTED] wrote:
Could someone please take a look at bug 31228 in bugzilla?
It's just adding a new response code (226) which is defined in rfc3229.
I'm working on a module that implements a type of rfc3229 delta encoding,
and
--On Monday, September 13, 2004 5:13 PM +0100 Joe Orton [EMAIL PROTECTED]
wrote:
On platforms with sizeof(int) == sizeof(apr_size_t), the change is a
noop, so no break there.
On other platforms, any indirect lock records which have already been
written to the database by the =2.0.50 code will be
--On Tuesday, September 7, 2004 4:27 PM +1000 Jason Rigby
[EMAIL PROTECTED] wrote:
I found that you can get mod_ssl included as a binary if you download
the binaries that include PHP and mod_perl. (That's how I got it
working for me) I think mod_ssl isn't included for some strange export
issues
--On Wednesday, September 8, 2004 2:51 PM -0700 Michael Corcoran
[EMAIL PROTECTED] wrote:
I've looked at the code a little bit (Apache 2.0.50), and at first glance,
it seems as though proper 304 response handling might not actually be fully
implemented yet. Is that actually the case, or am I
--On Tuesday, September 7, 2004 1:00 PM -0400 Jim Jagielski
[EMAIL PROTECTED] wrote:
True, but this is one that I'm hitting a lot, especially
with the increase in cache development going on...
And this is the only bundled module that I've hit this on
when httpd is build normally.
IMHO, the
--On Tuesday, September 7, 2004 2:48 PM +1000 Ian Holsman
[EMAIL PROTECTED] wrote:
ok.. so I've started playing with mod-cache again, and I noticed the
following:
- there is no way to cache something with query-args which doesn't return
a expires tag.
proposal: add a CacheIgnoreNoExpires
--On Friday, September 3, 2004 12:14 PM -0400 Jeff Trawick [EMAIL PROTECTED]
wrote:
I'm using head, with a spelling fix to mod_proxy comment (probably the
cause of the breakage) and a tweak to allow proxy connect to bypass
the balancer, and this silly testcase isn't working:
192.168.1.11 - -
--On Thursday, September 2, 2004 12:24 PM -0400 Geoffrey Young
[EMAIL PROTECTED] wrote:
I certainly understand the reason for this. however, I can't find any
documentation in the RC that notes the separation or gives useful APR
information - 2.0 was compile and go, while shipping 2.1 without
--On Thursday, September 2, 2004 12:24 PM -0400 Geoffrey Young
[EMAIL PROTECTED] wrote:
also, it might be nice for configure (or some earlier step) to determine
that the required APR foo wasn't found and balk at that step. or wherever
makes sense to those more familiar with the build system
--On Thursday, September 2, 2004 9:37 PM +0100 Joe Orton [EMAIL PROTECTED]
wrote:
Yeah, it is supposed to be like that, but the last cog hadn't quite
fallen into place: I fixed it just now for the next 2.1 build.
FWIW, I was waiting for APR 1.0.0 to go gold first before flipping that
switch.
--On Thursday, August 26, 2004 7:08 PM +0200 Sander Striker
[EMAIL PROTECTED] wrote:
I'm going to start a TR cycle for both 2.0 and 2.1 monday.
Objections?
Vote early and often for APR 1.0 so that 2.1 can use an official 1.0 release
of APR. ;-) -- justin
--On Monday, August 23, 2004 5:29 PM -0700 Max Cooper [EMAIL PROTECTED]
wrote:
I need a flood binary that I can run on my Linux box, but I am having
trouble building one.
I followed the build instructions on this web page:
http://httpd.apache.org/test/flood/building.html
apr and apr-util seem to
--On Tuesday, August 24, 2004 8:24 AM + [EMAIL PROTECTED] wrote:
mturk 2004/08/24 01:24:18
Modified:modules/proxy proxy_http.c
Log:
Use ap_str_tolower for lowercasing the scheme.
That was the original intention (not apr_tolower).
Can you please not mix formatting changes with
--On Tuesday, August 24, 2004 12:20 PM +0200 Graham Leggett
[EMAIL PROTECTED] wrote:
Putting on an end user hat I see no reason why AddOutputFilterByType
shouldn't do exactly what it says it does.
I believe it has more to do with mod_proxy than the filter design. No one,
at the time we added
--On Tuesday, August 17, 2004 4:52 PM -0500 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
I have the same concern... Madhu is gone for about another week,
I think you mean Mladen not Madhu. ;-) -- justin
--On Tuesday, August 17, 2004 1:03 AM +0200 André Malo [EMAIL PROTECTED] wrote:
Actually, I see no sense in restricting at compile time at all. As far as
I can see, we can just take the 8k config default and drop the upper
compile time limit.
+1. -- justin
--On Sunday, August 15, 2004 7:30 PM -0700 Mathihalli, Madhusudan
[EMAIL PROTECTED] wrote:
I thought the 8K limit was a compile-time constant.
http://httpd.apache.org/docs-2.0/mod/core.html#limitrequestfieldsize
8190 is just our default. HTH. -- justin
--On Friday, August 13, 2004 10:02 AM -0700 Mathihalli, Madhusudan
[EMAIL PROTECTED] wrote:
I was wondering if there's any potential harm in increasing the
LimitRequestFieldsize from it's current value of 8k to something more
(like 32k).
Instances that need to support larger header sizes
--On Thursday, August 12, 2004 12:57 AM -0500 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Although he's subscribed to all three lists, I'd ask that they go either
to [EMAIL PROTECTED] or [EMAIL PROTECTED] The history of the discussions is just
as important as the actual code commits.
Can we
--On Thursday, August 12, 2004 2:51 AM -0400 Glenn Strauss
[EMAIL PROTECTED] wrote:
/** The filter should pass any special buckets (not in-memory) as long
as it * does not need to perform any processing on them (translation
or protocol * delimiting) (augments AP_MODE_BYTES;
--On Thursday, August 12, 2004 2:10 AM +0200 André Malo [EMAIL PROTECTED] wrote:
There are also some showstoppers in 2.1 which I don't see resolved until
Oct 1 or Nov 1. IIRC Nick had also a kind of roadmap (?) posted some weeks
ago.This one should also reviewed.
Well, progress isn't going to
--On Thursday, August 12, 2004 4:20 PM -0400 Joshua Slive [EMAIL PROTECTED]
wrote:
I would hope we could make a statement like: Major security issues will be
addressed in 2.0 until at least [2.2 release date + 1 year].
If someone volunteers to be a 2.0 security RM, that'll happen. Otherwise, it
--On Thursday, August 12, 2004 3:52 PM -0400 Glenn Strauss
[EMAIL PROTECTED] wrote:
I saw so much repeated code for parsing brigades, that I created a
readahead API: ap_brigade_ra(). It is passed similar arguments as
those to input filters, and additionally is passed a readahead struct
and a
--On Thursday, August 12, 2004 5:03 PM -0400 Glenn Strauss
[EMAIL PROTECTED] wrote:
BRIGADE_NORMALIZE skips the bucket after a 0-length bucket.
In doing so, it might skip a 0-length bucket following it. If the last
IMHO, the cleanest correct fix is to just add an else clause. At the cost of
--On Thursday, August 12, 2004 6:24 PM -0400 Glenn Strauss
[EMAIL PROTECTED] wrote:
Right. I didn't say it was a problem in practice.
I did say that it was a terrible piece of code, and since this list
often refers people to look at the code, it should be fixed, IMHO.
It is a _bad_ and _broken_
--On Wednesday, August 11, 2004 4:24 PM +0100 Joe Orton [EMAIL PROTECTED]
wrote:
Any interest in this for HEAD? Patch below adds a test_config hook
which allows modules to do extra checking when httpd is invoked with -t.
The new -t -D DUMP_MODULES feature can be implemented this way rather
than
--On Wednesday, August 11, 2004 5:16 PM -0400 Glenn Strauss
[EMAIL PROTECTED] wrote:
I'm finding ap_input_mode_t very restrictive as a linear enum
and would like to make it an enum of bitflags.
Please back up a bit.
Why do you think the modes should be combined? -- justin
--On Wednesday, August 11, 2004 12:08 PM -0500 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Doesn't some de minimis treatment through the incubator still apply? There
are two templates, one for a full project's incubation, one for a lightweight
pass through IP vetting. ++1 here for submission
--On Saturday, August 7, 2004 8:49 AM +0200 Jan Kratochvil
[EMAIL PROTECTED] wrote:
according to RFC2616 (HTTP/1.1) section 4.4 it is valid to do POST method
without specifying Content-Length. Mobile phone SonyEricsson P900 sends
such requests to its specified WAP proxy (behaving in HTTP way - I
--On Saturday, August 7, 2004 9:18 AM +0200 Jan Kratochvil
[EMAIL PROTECTED] wrote:
Unfortunately httpd proxy will forward it dechunked although it will not
fill-in any Content-Length. httpd is no longer to handle it on its input
afterwards.
The sniffed forwarded request is at:
--On Saturday, August 7, 2004 6:14 PM +0100 Nick Kew [EMAIL PROTECTED] wrote:
We have a lot of proxy updates in 2.1, which are presumably getting
test-driven over time. How would one go about proposing a wholesale
backport?
How about releasing 2.2 instead? ;-)
Hmmm, did your fix merely chunk
This patch fully fleshes out Brian's earlier patch and tries to optimize
the header on-disk format. The current disk format didn't make any sense.
It also was full of security holes (reading into a 1034-byte char's). Only
the headers are still CRLF-delimited. We could go further and replace
--On Wednesday, August 4, 2004 5:26 PM +0200 Graham Leggett [EMAIL PROTECTED]
wrote:
How resilient is this to garbage data on the disk? A risk exists of somebody
getting write access to the headers cache file, and then crafting a cache
headers file which when read causes a takeover of the
--On Wednesday, August 4, 2004 8:56 AM -0400 Brian Akins
[EMAIL PROTECTED] wrote:
Sorry about this, but the last patch had a mistake in the writev
Looks okay - I'll take a look at incorporating it to my local changes and see
how it helps. The one thing I'd change is the sizeof(char) to
--On Tuesday, August 3, 2004 10:29 PM -0400 Bill Stoddard [EMAIL PROTECTED]
wrote:
mod_cache, mod_mem_cache and mod_disk_cache are experimental modules in 2.0,
so I am going to bypass the votes and just start backporting fixes. Please
review as they go in. If something breaks, we'll fix it. Mmmm
This patch removes the mod_cache dependencies upon the odd vtable and hooks
and standardizes upon the ap_provider_* API. mod_auth uses this provider
interface now as has mod_dav.
Besides removing a bunch of code, this has a number of beneficial side-effects:
- All operations related to a cache
--On Wednesday, August 4, 2004 12:39 PM -0700 Justin Erenkrantz
[EMAIL PROTECTED] wrote:
This patch removes the mod_cache dependencies upon the odd vtable and hooks
and standardizes upon the ap_provider_* API. mod_auth uses this provider
interface now as has mod_dav.
place bag over head
--On Wednesday, August 4, 2004 4:26 PM -0400 Brian Akins
[EMAIL PROTECTED] wrote:
Notice the plus in the second.
I thought about that, too. If you place it with the +1, then you'd be after
mod_deflate. I'm not yet fully sure what the implication of that would be.
Moving the filters around
--On Wednesday, August 4, 2004 4:52 PM -0400 Brian Akins
[EMAIL PROTECTED] wrote:
Possible scenerio:
Serving cached content:
- lookup uri in cache (via md5?).
- check varies - a list of headers to vary on
- caculate new key (md5) based on uri and clients value of these headers
- lookup new uri
--On Wednesday, August 4, 2004 5:18 PM -0400 Joshua Slive [EMAIL PROTECTED]
wrote:
But it couldn't be as expensive as caching a variant for every User-Agent
that accesses your site. What is probably needed is
CacheVaryOn env-variable
which would override the vary-matching decision to vary only
--On Monday, August 2, 2004 2:49 PM -0400 Bill Stoddard [EMAIL PROTECTED]
wrote:
To get mod_cache/mod_mem_cache (I know little or nothing about
mod_disk_cache) really performing competatively against best-of-breed caches
will require bypassing output filters (and prebuilding headers) and
--On Tuesday, August 3, 2004 8:11 AM -0400 Brian Akins [EMAIL PROTECTED]
wrote:
Under load, squid will always use 100% of the CPU. This is because it uses
poll/select.
Ouch. That sucks.
(But, httpd uses poll - so why does that force 100% CPU usage?)
RHEL 3 sucks. Fedora Core 2 would have been
--On Tuesday, August 3, 2004 9:12 AM -0400 Brian Akins [EMAIL PROTECTED]
wrote:
Propably not, because you would propably have to lock around it. It just
seems it's better to let the filesystem worry about alot of this stuff
(locking, reference counting, etc.).
+1. =) -- justin
--On Tuesday, August 3, 2004 6:50 PM +0200 Graham Leggett [EMAIL PROTECTED]
wrote:
mod_mem_cache: Requests: 35000 Time: 54.90 Req/Sec: 637.81
no cache: Requests: 35000 Time: 54.86 Req/Sec: 638.81
The above result would suggest that mod_mem_cache isn't being used in this
case. It could be
--On Tuesday, August 3, 2004 2:35 PM -0400 David Nicklay
[EMAIL PROTECTED] wrote:
Send us your squid.conf and your configure options from when you built it
(as well as what squid version), and I can tell you how to optimize it.
I've had a lot of practice..
I've posted the squid.conf from
--On Sunday, August 1, 2004 11:25 AM -0400 Bill Stoddard [EMAIL PROTECTED]
wrote:
Too many changes in one patch. Break this up into multiple consumable in 15
minute patches and I'll review them.
Some more work, analysis, and tests yielded apr_file_gets() and MD5 as two
more bottlenecks.
I've
--On Monday, August 2, 2004 10:35 AM -0400 Bill Stoddard [EMAIL PROTECTED]
wrote:
* modules/experimental/mod_disk_cache.c: Allow sendfile on cache bodies.
-1, Need to check for EnableSendfile off.
No, core_output_filter does that check. Modules don't have that information
whether
--On Monday, August 2, 2004 11:44 AM -0400 Bill Stoddard [EMAIL PROTECTED]
wrote:
These are debug messages so not sure why they are a problem.
+0
The logging code is expensive to call for every request like that as many
times as it does. IMHO, there's no benefit to such a verbose log. More
--On Sunday, August 1, 2004 11:25 AM -0400 Bill Stoddard [EMAIL PROTECTED]
wrote:
Too many changes in one patch. Break this up into multiple consumable in 15
minute patches and I'll review them.
Thanks for the review! I've committed all of the non-contentious ones (i.e.
sendfile and logging).
--On Sunday, August 1, 2004 11:25 AM -0400 Bill Stoddard [EMAIL PROTECTED]
wrote:
Too many changes in one patch. Break this up into multiple consumable in 15
minute patches and I'll review them.
Here's another patch that was hidden in my earlier one. I think 'read' and
'write' are awful terms
--On Monday, August 2, 2004 1:05 PM -0400 Bill Stoddard [EMAIL PROTECTED]
wrote:
I should amend my vote a -.5. The patch should work as you've coded it but
opening a file for use with apr_sendfile causes the file to be opened for
overlapped i/o on Windows. I expect some of the codepaths will
--On Monday, August 2, 2004 8:46 AM -0400 Brian Akins [EMAIL PROTECTED]
wrote:
Another big speed-up may be to pre-make all of the directories. A simple
script could use CacheRoot, |CacheDirLength|, and |CacheDirLevels to create
them all. Just require that this script be ran before starting a
--On Monday, August 2, 2004 9:21 AM -0400 Brian Akins [EMAIL PROTECTED]
wrote:
In a low traffic site, yes. In a very high traffic site, with lots of
objects, the mkdir's kill you. After a while, most of the directories
will be created. However, bringing up a fresh server behind a very busy
--On Monday, August 2, 2004 10:55 AM -0700 Justin Erenkrantz
[EMAIL PROTECTED] wrote:
--On Sunday, August 1, 2004 11:25 AM -0400 Bill Stoddard
[EMAIL PROTECTED] wrote:
Too many changes in one patch. Break this up into multiple consumable in 15
minute patches and I'll review them.
Here's another
--On Monday, August 2, 2004 2:54 PM -0400 Brian Akins
[EMAIL PROTECTED] wrote:
The other bottleneck I looked at was MD5 as the on-disk naming
scheme. I think MD5 is a poor choice here because it's not very
fast. Ideally, switching to a variant of the times-33 hash might
work out better.
--On Monday, August 2, 2004 3:01 PM -0400 Brian Akins
[EMAIL PROTECTED] wrote:
(and prebuilding headers)
Is there a way to send pre built headers? mod_asis uses
ap_scan_script_header_er which is fairly slow.
That was what I fixed with apr_file_gets() last night. The code there was
really
--On Monday, August 2, 2004 2:49 PM -0400 Bill Stoddard
[EMAIL PROTECTED] wrote:
To get mod_cache/mod_mem_cache (I know little or nothing about
mod_disk_cache) really performing competatively against best-of-breed
caches will require bypassing output filters (and prebuilding headers)
and
--On Monday, August 2, 2004 5:11 PM -0700 Roy T. Fielding
[EMAIL PROTECTED] wrote:
Hmm, IIRC, loading a cache means writing to it, not reading from it.
Why not just change them to cache_write and cache_read?
Or store and recall?
store and recall work, too. *shrug* (I share rbb's inability to
--On Monday, August 2, 2004 8:18 PM -0400 Cliff Woolley
[EMAIL PROTECTED] wrote:
Yeah, it's really good to see the interest in this picking back up. This
seems like a really good way to get us motivated to do a 2.2 release
Sometime Soon. :)
How 'bout 2.2 GA for ApacheCon? Seems reasonable to
While at OSCON last week, Madhu and I had a chat about mod_cache - and how
Zeus is beating httpd 2.x all over the place because they cache and we still
don't by default and about how poor a job mod_cache is doing in the real
world. Madhu has a bunch of gprof numbers that he said he'll be posting
--On Sunday, August 1, 2004 8:24 AM +0100 Nick Kew [EMAIL PROTECTED] wrote:
I'm not sure what 'match' is in this context.
In the above case, it could be text/html or latin1.
ap_register_smart_filter(transcode, latin1, charset_filter, ctx,
flags); ap_register_smart_filter(process, text/html,
--On Friday, July 16, 2004 11:29 PM -0400 Bill Stoddard [EMAIL PROTECTED]
wrote:
Pier Fumagalli wrote:
I don't understand why mod_cache forcedly avoids caching URLs ending
with the / (slash) character.
Yah, when I went through mod_cache tonight, I tossed that same code, too. I
agree that it
--On Tuesday, July 13, 2004 11:21 AM -0500 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Body/content generation or transformation should not be contending with
these issues you raised above. It's not unreasonable to expect some
metadata to pass through or be transformed (such as a content
--On Tuesday, July 13, 2004 10:35 AM -0500 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
The confusion results because mod_proxy isn't implemented as a content
handler, it's a protocol handler in its own right. Rather than insist on the
mod_http mod_proxy agreeing to streamline the response,
--On Sunday, August 1, 2004 10:54 AM +0100 Nick Kew [EMAIL PROTECTED] wrote:
(btw, if you think AP_FTYPE_RESOURCE should be AP_FTYPE_CONTENT_SET,
that's another weakness of the architecture. If we need to transcode
*before* a content filter, then we can't use CONTENT_SET.
Solution: this needs to
--On Sunday, August 1, 2004 11:26 AM +0200 Mladen Turk [EMAIL PROTECTED]
wrote:
-if ((rv = apr_socket_create(newsock, backend_addr-family,
+#if (APR_VERSION_MAJOR 0)
+if ((rv = apr_socket_create(
+#else
+if ((rv = apr_socket_create_ex(
+#endif
+
--On Tuesday, July 20, 2004 10:19 PM +0200 André Malo [EMAIL PROTECTED] wrote:
the old outdated NCSA config directives? We add and add and add code -- which
is not actually bad. But where's the man with the broom?
Sounds a like job for someone. How about nominating modules for removal in
2.1, or
--On Sunday, August 1, 2004 11:25 AM -0400 Bill Stoddard [EMAIL PROTECTED]
wrote:
Too many changes in one patch. Break this up into multiple consumable in 15
minute patches and I'll review them.
Okay. You asked for it. ;-) I wanted to let the patches sit overnight in my
head and then break
--On Sunday, August 1, 2004 11:25 AM -0400 Bill Stoddard [EMAIL PROTECTED]
wrote:
Too many changes in one patch. Break this up into multiple consumable in 15
minute patches and I'll review them.
* modules/http/http_request.c (ap_internal_redirect): Call quick_handler when
we do an internal
--On Sunday, August 1, 2004 11:25 AM -0400 Bill Stoddard [EMAIL PROTECTED]
wrote:
Too many changes in one patch. Break this up into multiple consumable in 15
minute patches and I'll review them.
* modules/experimental/mod_cache.h: Always use atomics.
* modules/experimental/mod_mem_cache.c:
701 - 800 of 1873 matches
Mail list logo
