hi all...
I just upgraded to libwww-perl 5.800 and found that a few POST tests started
failing where they didn't before, namely t/apache/post.t and t/http11/post.t.
I think the underlying problem is this change in HTTP::Message:
HTTP::Message will now allow an external 'content_ref'
to
On Tue, 03 Aug 2004 22:29:01 -0400, Bill Stoddard [EMAIL PROTECTED] wrote:
Bill Stoddard wrote:
Brian Akins wrote:
I think I missed the answer to this:
Has the feature that prevents mod_cache from caching urls ending in
/ (as related to mod_dir) been fixed? If so, will this
This speeds up writing and reading the metadata by using a struct
rather that all the calls to ap_cache_usec2hex
Note: I haven't actually tested this in mod_cache. Very similar code
works very well elsewhere.
--
Brian Akins
Senior Systems Engineer
CNN Internet Technologies
---
Sorry about this, but the last patch had a mistake in the writev
--
Brian Akins
Senior Systems Engineer
CNN Internet Technologies
--- httpd-2.0.50.old/modules/experimental/mod_disk_cache.c 2004-02-09
15:53:16.0 -0500
+++ httpd-2.0.50/modules/experimental/mod_disk_cache.c 2004-08-04
On Tue, 3 Aug 2004 01:23:36 +0200, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I noticed that %b directive in CustomLog *should* mean Bytes sent, excluding
HTTP headers but it doesn't seem to work like this. I think it just mean
Content-Length returned in HTTP-response.
Is there a way to get
Since these modules are experimental (still), the backport
procedure is (or should be) much more relaxed than with
non-exp modules. Heck, I would almost say that anything
added to the 2.1 tree for exp. modules should *always* be
added to the 2.0 tree as well (for experimental modules).
:)
Bill
At 09:29 PM 8/3/2004, Bill Stoddard 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 K?
+++1 - if folks can't understand
Note: I haven't actually tested this in mod_cache. Very similar code
works very well elsewhere.
Brian Akins wrote:
Sorry about this, but the last patch had a mistake in the writev
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
Do we care about backporting the overhaul into the 2.0 tree? I
don't see that it really buys us anything unless you think that it is
necessary in order to get auth_ldap out of experimental. After I get
the latest util-ldap fixes backported, that should get mod_auth_ldap
working in 2.0. Once
Graham Leggett 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
webserver. Just want to check that it's covered.
That exists for
Brad Nicholes wrote:
Do we care about backporting the overhaul into the 2.0 tree? I
don't see that it really buys us anything unless you think that it is
necessary in order to get auth_ldap out of experimental. After I get
the latest util-ldap fixes backported, that should get mod_auth_ldap
--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 Tue, 03 Aug 2004 23:47:21 -0500, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
At 09:29 PM 8/3/2004, Bill Stoddard 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
Jeff Trawick wrote:
On Tue, 03 Aug 2004 23:47:21 -0500, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
At 09:29 PM 8/3/2004, Bill Stoddard 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
--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 --
Should this:
cache_in_filter_handle =
ap_register_output_filter(CACHE_IN,
cache_in_filter,
NULL,
AP_FTYPE_CONTENT_SET-1);
Actually be this:
cache_in_filter_handle =
Brian Akins wrote:
Should this:
cache_in_filter_handle =
ap_register_output_filter(CACHE_IN,
cache_in_filter,
NULL,
AP_FTYPE_CONTENT_SET-1);
Actually be this:
cache_in_filter_handle =
On 4 Aug 2004 19:57:30 -, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
jerenkrantz2004/08/04 12:57:30
Modified:.Tag: APACHE_2_0_BRANCH STATUS
Log:
Hey, look, I can cast votes!
no way, what happened to the mysterious authentication which allowed
only a small number of
--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
Bill Stoddard wrote:
This is the area in which mod_cache is most broken. It does not handle
vary at all, thus the content needs to be stored before it is touched
by any filters. But that doesn't work either because some filters will
not properly run when serving content out of a quick_handler
--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
These's been a recent discussion over on the modperl list
(reference: http://marc.theaimsgroup.com/?t=10912298461r=1w=2)
with regards to C-L and HEAD requests. Dynamic handlers that know the
length of the content, but do not want to generate the content must send
something (anything) down the
On Wed, 4 Aug 2004, Justin Erenkrantz wrote:
--On Wednesday, August 4, 2004 4:52 PM -0400 Brian Akins
[EMAIL PROTECTED] wrote:
The thing that sucks is if you vary on User-Agent. You wind up with a ton
of entries per uri. I cheated in another modules by varying on an
environmental variable.
Brian Akins wrote...
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 in cache
- continue as normal
Don't forget that you can't just 'MD5' a
--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
jerenkrantz2004/08/04 12:57:30
--- STATUS4 Aug 2004 19:31:58 - 1.751.2.967
+++ STATUS4 Aug 2004 19:57:29 - 1.751.2.968
@@ -94,15 +94,19 @@
modules/experimental/util_ldap.c: 1.36
+1: minfrin (this requires the apr-util LDAP overhaul to be
APACHE 1.3 STATUS: -*-text-*-
Last modified at [$Date: 2004/05/20 15:16:42 $]
Release:
1.3.32-dev: In development
1.3.31: Tagged May 7, 2004. Announced May 11, 2004.
1.3.30: Tagged April 9, 2004. Not released.
1.3.29: Tagged October 24,
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2004/08/04 23:19:59 $]
Release:
2.0.51 : in development
2.0.50 : released June 30, 2004 as GA.
2.0.49 : released March 19, 2004 as GA.
2.0.48 : released October 29, 2003 as GA.
APACHE 2.1 STATUS: -*-text-*-
Last modified at [$Date: 2004/04/27 22:09:17 $]
Release [NOTE that only Alpha/Beta releases occur in 2.1 development]:
2.1.0 : in development
Please consult the following STATUS files for information
on related
33 matches
Mail list logo
