.
Dw.
On Sat, 24 Aug 2002, Ian Holsman wrote:
> I want to change mod_log_config so that the open/writing of the logfile
> can be overwritten by another module via optional functions.
>
> I think this would be handy for things log mod_log_spread and for people
> who have to write a
Hi,
I am working on mod_log_spread for apache 2.0. Old mod_log_spread for
apache 1.3 was based on some older version of mod_log_config and so it
is my new version based on (recent) mod_log_config from apache 2.0.54.
Right now any module which wants to implement custom logging has to
reimplement
Hi,
mod_log_config contains these lines
static const char *set_buffered_logs_on(cmd_parms *parms, void *dummy, int
flag)
{
buffered_logs = flag;
if (buffered_logs) {
ap_log_set_writer_init(ap_buffered_log_writer_init);
ap_log_set_writer(ap_buffered_log_writer
The CookieLog directive has been documented as deprecated since mod_log_config
was introduced, back in the 1.2 days. Any objection to axing it?
Index: docs/manual/mod/mod_log_config.xml
===
--- docs/manual/mod/mod_log_config.xml
Hey guys,
I'd like to tell about some problems i've had lately within mod_log_config. My company
wants to use a certain cookie our product issues throughout a buying process to track
our wanna-be-clients during their surfing to improve our buying process.
I've successfully
mod_log_config is "pluggable." You can "replace" the normal logging
functions quite easily.
Just do something like:
static apr_status_t my_logger_writer(request_rec *r,
void *handle,
On Mon, 2005-10-03 at 07:58 -0400, Brian Akins wrote:
>
> mod_log_config is "pluggable." You can "replace" the normal logging
> functions quite easily.
The word here is _replace_. If you "replace" ap_log_writer and
ap_log_writer_init you need t
Ondrej Sury wrote:
Even now when you want to make some log files buffered and some not you
are out of luck and this could also be solved by making plugging more
"general".
Ok I see what you mean and I agree. Maybe something stupid like a
SetLogHandler similar to SetHandler? or as an argume
On Mon, 2005-10-03 at 09:19 -0400, Brian Akins wrote:
> Ondrej Sury wrote:
>
> > Even now when you want to make some log files buffered and some not you
> > are out of luck and this could also be solved by making plugging more
> > "general".
>
>
> Ok I see what you mean and I agree. Maybe somet
Akins, Brian wrote:
Hmmm... Maybe custom loggers could be providers that have an init and a
writer function.
Maybe have customLog be something like this:
CustomLog mysql://something common env=images
CustomLog file:///logs/my.log combined
CustomLog spread://somegroup refere
CustomLog buffer:
Ondrej Sury wrote:
You also need to store which writer to use in each config_log_state.
This is already done.
Also, init is called for each CustomLog config entry.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
On Mon, 2005-10-03 at 09:35 -0400, Brian Akins wrote:
> Ondrej Sury wrote:
>
> > You also need to store which writer to use in each config_log_state.
>
> This is already done.
Nope, (void *)cls->log_writer is pointer to log file descriptor.
> Also, init is called for each CustomLog config entry
writer_init retures whatever you function returns. In
mod_log_config, it's an apr_file_t *.
Currently, however, log_writer_init is global. It should be per cls, or
per server.
Also, init is called for each CustomLog config entry.
Yep, but only ap_log_writer_init is called. You need t
a socket. See, open_config_log
>
> cls->log_writer = log_writer_init(p, s, cls->fname);
>
> log_writer_init retures whatever you function returns. In
> mod_log_config, it's an apr_file_t *.
Sorry for not being accurate. My point was that cls->log_writer hold
logger *data
hi all :)
a co-worker and I were just adding some functionality to an internal
httpd module when we noticed that mod_log_config misbehaves when logging
cookie values...
in short, we have a cookie FOO and were adding a cookie CLIENT_FOO. in
the log format we used
%{FOO}C\t%{CLIENT_FOO}C
but
Apache won't initialize... look at the name passed when
opening/creating the file:
open("logs/access_log", O_WRONLY|O_APPEND|O_CREAT, 0666) = -1 ENOENT (No such file or
directory)
gettimeofday({1030448472, 125843}, NULL) = 0
write(2, "[Tue Aug 27 11:41:12 2002] [erro"..., 115) = 115
_exit(1)
-
On Thursday, March 03, 2011 13:44:57 Torsten Förtsch wrote:
> I have found that in 2.2.17. But I have verified it is also present in
> trunk.
Now filed as https://issues.apache.org/bugzilla/show_bug.cgi?id=50861
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.nam
Thx for the report and the patch... I will verify and apply
to trunk w/ a backport req for 2.2.
On Mar 3, 2011, at 8:45 AM, Torsten Förtsch wrote:
> On Thursday, March 03, 2011 13:44:57 Torsten Förtsch wrote:
>> I have found that in 2.2.17. But I have verified it is also present in
>> trunk.
>
>
On Thursday, March 03, 2011 14:55:40 Jim Jagielski wrote:
> Thx for the report and the patch... I will verify and apply
> to trunk w/ a backport req for 2.2.
any progress on that?
> On Mar 3, 2011, at 8:45 AM, Torsten Förtsch wrote:
> > On Thursday, March 03, 2011 13:44:57 Torsten Förtsch wrote:
On Thursday, March 03, 2011 14:55:40 Jim Jagielski wrote:
> Thx for the report and the patch... I will verify and apply
> to trunk w/ a backport req for 2.2.
Just a polite reminder.
> On Mar 3, 2011, at 8:45 AM, Torsten Förtsch wrote:
> > On Thursday, March 03, 2011 13:44:57 Torsten Förtsch wrote
On Mar 15, 2011, at 5:45 AM, Torsten Förtsch wrote:
> On Thursday, March 03, 2011 14:55:40 Jim Jagielski wrote:
>> Thx for the report and the patch... I will verify and apply
>> to trunk w/ a backport req for 2.2.
>
> Just a polite reminder.
>
>> On Mar 3, 2011, at 8:45 AM, Torsten Förtsch wrot
On Thursday, March 17, 2011 16:05:12 Jim Jagielski wrote:
> Added in r1082518.
Thanks.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
On 19 Sep 2011, at 1:28 AM, Rich Bowen wrote:
The CookieLog directive has been documented as deprecated since
mod_log_config was introduced, back in the 1.2 days. Any objection
to axing it?
Axe it, +1.
Regards,
Graham
--
smime.p7s
Description: S/MIME cryptographic signature
bye bye :)
On Sep 18, 2011, at 7:28 PM, Rich Bowen wrote:
> The CookieLog directive has been documented as deprecated since
> mod_log_config was introduced, back in the 1.2 days. Any objection to axing
> it?
>
>
>
>
> Index: docs/manua
Akins, Brian wrote:
CustomLog mysql://something common env=images
CustomLog file:///logs/my.log combined
CustomLog spread://somegroup refere
CustomLog buffer:///logs/other.log common
This patch implements the above. Within mod_log_config two providers
are provided: file and buffer. If no
I'm playing around with a patch for mod_log_config that would enable
logging of the number bytes received per request. That kind of
information would then be very useful for determining input traffic per
virtual host, URL or whatever else, using regular web analysis tools,
e.g. webalizer.
On Mon, Oct 03, 2005 at 11:40:27AM -0400, Brian Akins wrote:
> >CustomLog mysql://something common env=images
> >CustomLog file:///logs/my.log combined
> >CustomLog spread://somegroup refere
> >CustomLog buffer:///logs/other.log common
>
> This patch implements the
Colm MacCarthaigh wrote:
Looks useful, but file://|/bin/foo would be very non-intuitive for piped
loggers, balancing the backwards compatibility might need a bit more, I
guess "pipe://" or "cmd://" schemes might make sense also.
True. I just used uri's as they seemed to just "fit." I'm not
Brian Akins wrote:
>
> Colm MacCarthaigh wrote:
>
> > Looks useful, but file://|/bin/foo would be very non-intuitive for piped
> > loggers, balancing the backwards compatibility might need a bit more, I
> > guess "pipe://" or "cmd://" schemes might make sense also.
>
>
> True. I just used uri
Jim Jagielski wrote:
'pipe' is clearer I think...
sure. Of course I just discovered that pip logs don't work. I think
it's the spaces in the command, ie "|bin/rotatelogs /var/logs/logfile
5M". Hmmm.. looking into it...
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
On 10/03/2005 08:49 PM, Colm MacCarthaigh wrote:
> On Mon, Oct 03, 2005 at 11:40:27AM -0400, Brian Akins wrote:
>
[..cut..]
>
> Looks useful, but file://|/bin/foo would be very non-intuitive for piped
I guess you still can use |/bin/foo because file is the default provider.
> loggers, balanc
Rüdiger Plüm wrote:
Makes also sense to me since it seems to me that piped logging does not really
play
well with other things like spread or mysql. On the other side, what about the
buffered logging? Would it make sense to make it possible to turn this on
and off with each provider? If yes, we
@ -30,7 +30,7 @@
* callback function prototype for external writer initialization.
*/
typedef void *ap_log_writer_init(apr_pool_t *p, server_rec *s,
- const char *name);
+ const apr_uri_t *uri);
/**
* callback which gets called
;
> This patch implements the above. Within mod_log_config two providers
> are provided: file and buffer. If no "scheme" is given, file is assumed.
>
> I have tested and preliminarily it works for both file and buffer. I
> had to rearrange some of the buffer code to get
Ondrej Sury wrote:
Just quick thought, maybe we should add:
ap_log_writer_close *close;
to struct log_provider_t. It's not absolutely necessary, because you
can use apr_pool_cleanup_register(...), but it will make writing addon
modules much cleaner.
That's debatable. I already use apr_pool
On 10/03/2005 09:11 PM, Brian Akins wrote:
> Rüdiger Plüm wrote:
>
>> Makes also sense to me since it seems to me that piped logging does
>> not really play
>> well with other things like spread or mysql. On the other side, what
>> about the
>> buffered logging? Would it make sense to make it po
sense that mod_log_config does
it. mod_log_config just keeps appending data to a buffer. in an sql
logger, to "buffer" you would keep a list/array/ring of log lines and
wrap them in a transaction. This cannot be "buffered" in mod_log_config
Hm, the question i
On 10/3/05, Brian Akins <[EMAIL PROTECTED]> wrote:
Rüdiger Plüm wrote:>> Or it likes to read many lines in one block as it can commit such things> as a batch rather than as single commits per line. Of course it is not required> to use DB transactions on mysql. But for Oracle this might improve perf
On 10/03/2005 09:53 PM, Brian Akins wrote:
> Rüdiger Plüm wrote:
>
[..cut..]
>
> but that would not be buffering in the sense that mod_log_config does
> it. mod_log_config just keeps appending data to a buffer. in an sql
> logger, to "buffer" you would keep a
On Mon, 2005-10-03 at 15:40 -0400, Brian Akins wrote:
> Ondrej Sury wrote:
>
> > Just quick thought, maybe we should add:
> >
> > ap_log_writer_close *close;
> >
> > to struct log_provider_t. It's not absolutely necessary, because you
> > can use apr_pool_cleanup_register(...), but it will make
On Mon, Oct 03, 2005 at 11:40:27AM -0400, Brian Akins wrote:
> Akins, Brian wrote:
>
> >CustomLog mysql://something common env=images
> >CustomLog file:///logs/my.log combined
> >CustomLog spread://somegroup refere
> >CustomLog buffer:///logs/other.log common
I've been looking more at this, and I
Colm MacCarthaigh wrote:
But in order to save overhead, this would require some intelligence, it
would not make much sense for the pluggable logger to re-parse this
string everytime, to figure out what it should be doing. And where does
it get its database, username and host information from? D
I run a system with about 250 virtual hosts averaging around 100 hits per
second with little problem. Rather than having a piped log for each
virtual host though, we only use one piped log for every virtual host, and
add in the host name into the log. Your logging program then has ot have
the smart
Jeffrey Burgoyne wrote:
I run a system with about 250 virtual hosts averaging around 100 hits per
second with little problem.
100 hits per second is not that much relative to what we do. We may be
more of an extreme case, though.
Rather than having a piped log for each
virtual host thoug
es to provide the
database, hostname, username and so on information. If such directives
are required anyway, what effort are we saving? Why not just replace
mod_log_config rather than plug into it.
> >And after all of this, what if any, are the compelling reasons to
> >implement this in
On Mon, 2005-10-03 at 23:28 +0100, Colm MacCarthaigh wrote:
> And after all of this, what if any, are the compelling reasons to
> implement this in httpd at all? Why can't all of this be moved into
> piped loggers? Why can't they just parse the logs as they get them and
> do whatever whoever wants
On Tue, Oct 04, 2005 at 02:59:40PM +0200, Ondrej Sury wrote:
> No, it cannot be implemented with two netcat commands (just tried it).
Sure, it can, use my Multicast Netcat;
http://people.heanet.ie/~colmmacc/mnc/
(version 1.3 is experimental and not working right now, avoid that, and
I'm
CustomLog mysql://mysql0/bar foo
Then ap_mysql_log_writer would do it's own processing of strs/strl
combo.
> And we still need additional per-provider directives to provide the
> database, hostname, username and so on information.
That's true.
> If such directives are required an
On Tue, 2005-10-04 at 14:06 +0100, Colm MacCarthaigh wrote:
> On Tue, Oct 04, 2005 at 02:59:40PM +0200, Ondrej Sury wrote:
> > No, it cannot be implemented with two netcat commands (just tried it).
>
> Sure, it can, use my Multicast Netcat;
Didn't know that anything like that exists. My comment
If such directives
are required anyway, what effort are we saving? Why not just replace
mod_log_config rather than plug into it.
Because mod_log_config handles a bunch of stuff for us. May be a better
solution would be to use the standard log_config way of replacing init
and writ
On Tue, Oct 04, 2005 at 09:15:32AM -0400, Brian Akins wrote:
> Why not just replace mod_log_config rather than plug into it.
>
> Because mod_log_config handles a bunch of stuff for us. May be a
> better solution would be to use the standard log_config way of
> replacing init
On 10/4/05, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 04, 2005 at 02:59:40PM +0200, Ondrej Sury wrote:
> > No, it cannot be implemented with two netcat commands (just tried it).
>
> Sure, it can, use my Multicast Netcat;
>
> http://people.heanet.ie/~colmmacc/mnc/
>
> (versi
My problem with piped loggers is there is no fast way to make sure you
have a "complete" line. This is especially hard when you buffer the logs.
Think of a situation where the piped logger is supposed to write to a
socket, for example. If the piped logger has the ability to "fail over"
to a
On Thu, Oct 06, 2005 at 02:06:24PM -0400, Brian Akins wrote:
> My problem with piped loggers is there is no fast way to make sure you
> have a "complete" line. This is especially hard when you buffer the logs.
If httpd writes a complete line, to any kind of a file descriptor,
anything beyond tha
message could be many log lines)
That way it's easy to ensure you get complete log entries and detect
when you don't. I could write a piped logger that did this, but I'd
have to detect when the lines begin and end and mod_log_config already
knows that.
Yes, for 90+% of the time,
On Thu, Oct 06, 2005 at 03:49:10PM -0400, Brian Akins wrote:
> Colm MacCarthaigh wrote:
>
> >If httpd writes a complete line, to any kind of a file descriptor,
> >anything beyond that is out of our control and becomes a question of the
> >quality of the piped logger, filesystem or whatever else is
The call to apr_explode_localtime() in mod_log_config is one of the more
expensive operations in the httpd. This patch attempts to reduce the
overhead by caching the result.
--Brian
Index: modules/loggers/mod_log_config.c
===
RCS
Taylor - [EMAIL PROTECTED] - The guy with the PS2 WebServer -
http://www.x-bb.org/chris.asc
- - Original Message -
From: "Bojan Smojver" <[EMAIL PROTECTED]>
To: "Apache Dev List" <[EMAIL PROTECTED]>
Sent: Sunday, August 18, 2002 11:25 PM
Subject: [PROPOSAL]
Quoting Chris Taylor <[EMAIL PROTECTED]>:
> Yes, definately.
>
> FWIW, I find it quite annoying that Webalizer's "amount served" is
> often blindingly inaccurate based on Apache's logs.
I think this is due to the fact that headers are not taken into account or
something like that. And there is
On Mon, Aug 19, 2002 at 08:25:53AM +1000, Bojan Smojver wrote:
> I'm playing around with a patch for mod_log_config that would enable
> logging of the number bytes received per request. That kind of
> information would then be very useful for determining input traffic per
> vir
Quoting Justin Erenkrantz <[EMAIL PROTECTED]>:
> On Mon, Aug 19, 2002 at 08:25:53AM +1000, Bojan Smojver wrote:
> > I'm playing around with a patch for mod_log_config that would enable
> > logging of the number bytes received per request. That kind of
> > infor
t who) fixed up the filters
so that a connection-level filter always has a reference to the
'current' request.
So, even in a connection-level filter, filter_rec->r should be valid.
You'd have to determine some place to store how much we read, but
that could be done in a mod_log_config private structure.
Hope this makes some sense. -- justin
In Apache 2 mod_log_config exposes an interface (via optional functions
ap_log_set_writer_init and ap_log_set_writer) that allows the log writer
to be replaced. I've used that interface to implement mod_log_rotate
which does time based log rotation in a similar way to rotatelogs.
Th
In Apache 2 mod_log_config exposes an interface (via optional functions
ap_log_set_writer_init and ap_log_set_writer) that allows the log writer
to be replaced. I've used that interface to implement mod_log_rotate
which does time based log rotation in a similar way to rotatelogs.
Th
%{tid}P gets you thread id in decimal now.
%{hextid}P would show it in hex using relatively new apr_sprintf()
format, added in 1.2.0.
Index: modules/loggers/mod_log_config.c
===
--- modules/loggers/mod_log_config.c(revision 240100)
On Sunday 09 September 2001 19:46, Brian Pane wrote:
Can we get this as a unified diff?
Ryan
> The call to apr_explode_localtime() in mod_log_config is one of the more
> expensive operations in the httpd. This patch attempts to reduce the
> overhead by caching t
Ryan Bloom wrote:
>On Sunday 09 September 2001 19:46, Brian Pane wrote:
>
>Can we get this as a unified diff?
>
sure, here's the unified form:
Index: modules/loggers/mod_log_config.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/l
On Sun, 9 Sep 2001, Brian Pane wrote:
> The call to apr_explode_localtime() in mod_log_config is one of the more
> expensive operations in the httpd. This patch attempts to reduce the
> overhead by caching the result.
Looks quite reasonable... I wouldn't mind seeing this as a
l, for fun.
Bill
- Original Message -
From: "Brian Pane" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, September 09, 2001 9:46 PM
Subject: [PATCH] performance patch for mod_log_config
> The call to apr_explode_localtime() in mod_log_config is one of
On Sun, 9 Sep 2001, William A. Rowe, Jr. wrote:
> Is this the right place to be caching, or should this become a
> straightforward optimization to apr's time.c functions? I'd think the
> advantages are many for keeping 15 current seconds in apr, and would
> pay off across the board. Within apr,
terface looks useful, I'll resubmit the patch in a form that
adds these functions to APR and calls them from mod_log_config.
--Brian
On Sun, 9 Sep 2001, Brian Pane wrote:
> I think putting it in APR would work. The one limitation I can think of
> is that adding the cache in apr_explode_localtime() itself wouldn't be a
> win because we'd have to add the overhead of a gettimeofday() call to
> check whether the supplied time was
Brian Pane wrote:
> William A. Rowe, Jr. wrote:
>
>> Is this the right place to be caching, or should this become a
>> straightforward
>> optimization to apr's time.c functions? I'd think the advantages are
>> many for
>> keeping 15 current seconds in apr, and would pay off across the
>> boar
Here's an updated version of the patch that fixes the
race condition that Dean pointed out involving requests
that last almost exactly 15 seconds. The comments in
the code describe the "snapshot" technique that it uses
to detect and correct the race condition.
--Brian
Index: modules/loggers/mod
The same patch reworked for Apache 2.0.
Justin, I had a look through filter examples but didn't feel confident
to undertake writing one. Maybe in the next version of the patch...
Bojan
--- mod_log_config.c.original Tue Aug 20 15:12:32 2002
+++ mod_log_config.cTue Aug 20 15:39:09 2002
@@
I have noticed a bug in my second version of the patch which would
report incorrect number of bytes sent if the request is HEAD. It is
fixed in this version. I have attached the documentation patch again,
just to avoid confusion.
Bojan
PS. At this rate, my e-mail address will end up on Apache sp
Hi,
we have ap_errorlog_provider in the trunk for some time. I was thinking
about extending it to mod_log_config, so CustomLog/TransferLog would
work with any module providing error_log logging ability like mod_syslog
or mod_journald.
Attached patch does that by introducing CustomLog
Hi,
I wasn't too happy with the current mod_log_config design, which turned
out to be a bit unflexible in the writer section, so I modified it in
order to be able to happily log into a database. The disadvantages of
the existing set_writer way of doing things are:
a) The log writer doesn&
Hi,
I wasn't too happy with the current mod_log_config design, which turned
out to be a bit unflexible in the writer section, so I modified it in
order to be able to happily log into a database. The disadvantages of
the existing set_writer way of doing things are:
a) The log writer doesn&
Hi
The Format String "%{Foobar}o" (The contents of Foobar: header line(s)
in the reply.) shown at
http://httpd.apache.org/docs/2.2/mod/mod_log_config.html does not work
for every reply header sent by the server. Instead, it give "-".
For example, Content-type works, but Date or Server do not. Is
On Sat, Aug 27, 2005 at 11:12:24AM -0400, Jeff Trawick wrote:
> %{tid}P gets you thread id in decimal now.
> %{hextid}P would show it in hex using relatively new apr_sprintf()
> format, added in 1.2.0.
Seems fine except that it introduces a softish dependency on apr >=
1.2.0 which is not enforced
On Tue, Aug 30, 2005 at 11:28:37AM +0100, Joe Orton wrote:
> On Sat, Aug 27, 2005 at 11:12:24AM -0400, Jeff Trawick wrote:
> > %{tid}P gets you thread id in decimal now.
> > %{hextid}P would show it in hex using relatively new apr_sprintf()
> > format, added in 1.2.0.
>
> Seems fine except that it
---
modules/loggers/mod_log_config.c | 159 +--
1 file changed, 153 insertions(+), 6 deletions(-)
diff --git a/modules/loggers/mod_log_config.c b/modules/loggers/mod_log_config.c
index d142c888ad..188131ebac 100644
--- a/modules/loggers/mod_log_config.c
+++ b/modules/l
Here is the patch that calculates (in the same way mod_accounting, by
Simone Tellini, does) the number of bytes received and bytes sent per
request. The numbers are then logged using %I (input) and %O (output).
Since the numbers are always greater then 0, there are no CLF versions
of those functio
f(r->pool, "%ld", recv);
> +}
The problem here is that the length may not be specified via C-L,
but rather Transfer-Encoding: chunked. This system falls down
in that case. This is why I'd strongly recommend looking at
trying to add r->bytes_read (or perhaps to a mod_log_c
ol, "%ld", recv);
> > +}
>
> The problem here is that the length may not be specified via C-L,
> but rather Transfer-Encoding: chunked. This system falls down
> in that case. This is why I'd strongly recommend looking at
> trying to add r->bytes_read (or perh
ead (or perhaps to a mod_log_config specific
> structure) to core_input_filter.
After reading a bit more from the function core_input_filter, here is
what I can conclude:
- to get to request from the filter, one would use f->r in that function
- since there is no r->bytes_read in
On Tue, Aug 20, 2002 at 09:54:43PM +1000, Bojan Smojver wrote:
> After reading a bit more from the function core_input_filter, here is
> what I can conclude:
>
> - to get to request from the filter, one would use f->r in that function
> - since there is no r->bytes_read in current request_rec we
instance
bytes_pushed and bytes_pulled, which would record the above (i.e. the
number of bytes actually read/written for the request, as per
core_input_filter and core_output_filter). Those can then be used for
logging purposes and statistics, together with the old bytes_sent.
bytes_sent would then get the lo
Quoting Justin Erenkrantz <[EMAIL PROTECTED]>:
> > So, r->bytes_sent would then be completely different that in the
> current
> > version of Apache 1.3/2.0, which simply reflects the length of the
> body?
> > Would others be inclined to accept such a change?
>
> Totally. The current behavior is
On 04/07/2015 11:47 AM, Jan Kaluža wrote:
Hi,
we have ap_errorlog_provider in the trunk for some time. I was thinking
about extending it to mod_log_config, so CustomLog/TransferLog would
work with any module providing error_log logging ability like mod_syslog
or mod_journald.
Attached patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'd like to close bug 28832 but it's a little unsatisfying to document a
feature as broken and leave it at that.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28832
Summary. In mod_log_config, %b returns an incorrect value in some cases.
* Sönke Tesch wrote:
> That said, I'm a bit unsure if the implementation is correct and bug-free,
> although it seems to work on my own server - after all, I'm new to this.
> I'd be happy about any helpful comments on design issues and other thoughts
> and suggestions.
Thanks! Sounds like an inte
Laurent Perez wrote:
For example, Content-type works, but Date or Server do not. Is
"%{Server}o" the right syntax to log the "Server:" header, or is it
broken ? An ethereal trace shows a value for the Server: header.
Server and Date are added later and cannot be overridden, but it probably
mak
Cliff Woolley wrote:
>On Sun, 9 Sep 2001, Brian Pane wrote:
>
>>I think putting it in APR would work. The one limitation I can think of
>>is that adding the cache in apr_explode_localtime() itself wouldn't be a
>>win because we'd have to add the overhead of a gettimeofday() call to
>>check wheth
Just noticed that there is a little bit of silliness (as usual) in the
original patch. Nothing serious, but this one should make a bit more
sense...
Bojan
--- mod_log_config.c.original Tue Aug 20 12:51:20 2002
+++ mod_log_config.cTue Aug 20 13:33:50 2002
@@ -151,6 +151,8 @@
* %...m: th
The %b option is used to log the 'bytes_sent' in a reply. Unlike %B, %b should log a '-' rather than '0' if no
body is sent on a reply. I recently ran across two cases where %b incorrectly logs '0': First case is when
ap_set_byterange sets HTTP_RANGE_NOT_SATISFIABLE to the default_handler. Sec
---
Se l'email che mi hai mandato è spam, interrompi subito il tuo atto criminoso.
If the email that you have sent me is spam, you immediately interrupt your
criminal action.
Greetings,
Trunk can log connection source port by using in Logformat : "%{remote}p".
2.2 currently does not support that (only logs the destination port of
the connection).
Included is a very simple (trivial) backport of that functionnality from
trunk to 2.2.
Tested, works for me.
Vincent
why is there a need for 15 entries? if it's a multiprocess server then
there's only a need for 1 or 2 entries. if it's a multithreaded server
then you need to lock the cache (which you're not doing :)
isn't the real win in eliminating both the divisions required by the
explode time functions an
1 - 100 of 145 matches
Mail list logo
