On Fri, 2002-10-11 at 20:59, William A. Rowe, Jr. wrote:
Let's get cracking and we can have a 2.1 release out by year end,
depending on how far we go with changes in that version. Certainly
some of the file-based stuff can finally be separated out, even if not
as radically as GStein has
On Sat, 2002-10-12 at 13:21, [EMAIL PROTECTED] wrote:
What we are learning here is simple. We need to do the counting in the
core_output_filter. If that means adding a field to the conn_rec, or
somehow getting the request_rec in the core_output_filter doesn't
matter. The count needs to be
Nope, that doesn't work. The number is always zero.
Bojan
On Sat, 2002-10-12 at 12:22, Bojan Smojver wrote:
Anyway, I think what's causing this problem is the fact that mod_logio
calculates the length of all brigades that are ready to be sent out. If
the sending gets interrupted in the
On 12 Oct 2002, Bojan Smojver wrote:
On Fri, 2002-10-11 at 18:58, David Burry wrote:
This should also be a concern for anyone who's using mod_logio to charge for
bandwidth, because customers should be concerned about some serious
overcharging going on here!
Only if you charge for
What we are learning here is simple. We need to do the counting in the
core_output_filter. If that means adding a field to the conn_rec, or
somehow getting the request_rec in the core_output_filter doesn't
matter. The count needs to be done in the core_output_filter, by tallying
the amount of
[EMAIL PROTECTED] wrote:
What we are learning here is simple. We need to do the counting in the
core_output_filter. If that means adding a field to the conn_rec, or
somehow getting the request_rec in the core_output_filter doesn't
matter. The count needs to be done in the core_output_filter,
Ok, [overly?] provocative title. Let me illustrate, however;
http://httpd.apache.org/docs-2.0/mod/
See any authn_foo/authz_foo? No, not at the moment. Once we
do, how on this green earth do we propose to provide online docs
for 2.0.43 and a hypothetical 2.0.44 with the auth overhaul? Folks
I have run into a problem where the cache code randomly decides that a
cached entry is stale or that the last modified date is some time in
the future. I tracked it back to the ap_cache_check_freshness code
which does a lot of checking of dates.
Some of this date checking code compares and
On Fri, 2002-10-11 at 16:04, Paul J. Reder wrote:
I have run into a problem where the cache code randomly decides that a
cached entry is stale or that the last modified date is some time in
the future. I tracked it back to the ap_cache_check_freshness code
which does a lot of checking of
At first glance, I think there's an even more fundamental problem:
the code in ap_cache_check_freshness() appears to be mixing times
measured in microseconds (the result of ap_cache_current_age())
with times measured in seconds (everything that it gets from the
HTTP header).
And does that
At 10:21 PM 10/11/2002, [EMAIL PROTECTED] wrote:
What we are learning here is simple. We need to do the counting in the
core_output_filter. If that means adding a field to the conn_rec, or
somehow getting the request_rec in the core_output_filter doesn't
matter. The count needs to be done in
11 matches
Mail list logo
