[PATCH] mod_log_config : 2.2 extended port logging backport from trunk
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
mod_log_config_extended_port_logging.patch.gz
Description: application/gzip
Analyze mod_rewrite log in browser
I am the developer of FirePHP (http://www.firephp.org/) which is a
debugging tool for PHP. It allows you to print debug messages from PHP
on the server to the Firebug (http://www.getfirebug.com/) Console. It
sends the debug data in the response headers instead of the response
body so that page rendering in the browse is not affected.
I was wondering if it would be useful for a lot of mod_rewrite users to
be able to view the rewrite log in their Firebug console instead of
having to go to the server logs. FirePHP could display the rewrite log
in a custom renderer that presents the log data in a more intuitive
format with links to reference documentation etc...
There could be a new configuration directive for mod_rewrite that
enables the sending of the rewrite log for specific IP's for instance.
This would also be useful in that rewrite logging would not need to be
turned on for all users.
The data in the header looks something like this:
X-FirePHP-Data-1001 {
X-FirePHP-Data-3001 "FirePHP.Firebug.Console":[
X-FirePHP-Data-3999 ["__SKIP__"]],
X-FirePHP-Data- "__SKIP__":"__SKIP__"}
X-FirePHP-Data-2001 "FirePHP.Dump":{
X-FirePHP-Data-2999 "__SKIP__":"__SKIP__"},
X-FirePHP-Data-355892512100 ["LOG","Hello World"],
X-FirePHP-Data-355892528800 ["LOG","Log message"],
X-FirePHP-Data-355892542900 ["INFO","Info message"],
X-FirePHP-Data-355892557000 ["WARN","Warn message"],
X-FirePHP-Data-355892571600 ["ERROR","Error message"],
X-FirePHP-Data-355892599600 ["LOG",["Label","Message with label"]],
It is simply a JSON (http://www.json.org) string that is broken up into
different sections which are sorted by their numeric index. mod_rewrite
could thus insert its log messages into an existing structure or
create its own if it did not receive one from the application.
You can see how this looks in the Firebug Console at:
http://www.firephp.org/
Is this something that would be useful to have for mod_rewrite users?
Could this be added to the default mod_rewrite module? A separate module?
Looking forward to your feedback.
Christoph
Re: AuthzMergeRules directive
>>> On 4/14/2008 at 3:29 PM, in message <[EMAIL PROTECTED]>, Chris Darroch <[EMAIL PROTECTED]> wrote: > Brad Nicholes wrote: > >> This is where it starts to go wrong for me. Where it gets confusing >> for somebody who is trying to figure out what the configuration >> is doing is: >> >> >> >>Require ip 10.10.0.1 >>Require ldap-group sales >> >> Require ldap-group ne-sales >> Require ldap-group sw-sales >> >> >> >> >> >> AuthzMergeRules SatisfyOne >> >>Require ldap-group marketing >>Require ldap-group alt-marketing >> >> >> >> Now I have to reconcile the logic of the parent with the logic of >> both the AuthzMergeRules and the tag. Even though it >> might not always look like the cleanest configuration, I think it >> will be less confusing if the logic rules were confined to >> the and tags rather than introducing >> alternate logic directives. > [snip] >If you'd like to stick to just "Off" (my proposed default for > AuthzMergeRules) and "On", perhaps AND should be the logic implemented > by "On"? Consider the following, where AND'ing helps tighten > security as you go down the tree: > [snip] >Personally, I'm gradually coming around to the feeling that AND is > more useful/secure than OR when merging per-dir blocks, and possibly > even within a single per-dir block (although that's another conversation), > and so should either be an option to AuthzMergeRules or the action > implemented by "On" if there are only two states. > >The reason I say it might make sense to AND authz requirements > within a block is that it "reads" a little more naturally. Consider > the following, which suggests to me that I need a shirt and shoes > to be served, not one or the other: > > > Require shirt on > Require shoes on > > >At rate rate, thanks for hashing through all my scattershot ideas > on this stuff. > I could go along with switching the default merging rule from OR to AND, even within a dir block. The reason why it is OR today was basically for backward compatibility. Since there really wasn't any kind of logic before, OR was just the default. If we switch to AND as being the default within a dir block, it may break some existing configurations. However I also think that AND is a safer merging rule going forward. Brad
Re: [PROPOSAL] Time Based Releases
Brad Nicholes wrote: IOW, we may be required to be conservative when it comes to 1.3.x, 2.0.x or 2.2.x, s/be required/desire/ - it's a group consensus. It wasn't this way prior to the 2.0.43 and doesn't have to be that way in the future, but I think it has served our users well, and hasn't gotten in our way until... but the same level of conservatism shouldn't apply to 2.4 or 3.0. ++1 Bill
