perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: Modifying the Apache Log Entry
Date Wed, 10 Jan 2007 17:25:39 GMT

>>>    connection, canonical_filename, header_only, main, next, prev,
>>>    pool, per_dir_config, request_config, proto_num, protocol,
>>>    request_time, server, the_request, unparsed_uri
>> opening up $r->request_line() is probably acceptable.  I'd also consider
>> protocol and maybe proto_num (after researching what it is),
>> unparsed_uri, and perhaps header_only.  but that's about all.
>> thoughs from other devs?
> I think one of the biggest gains I made as a programmer was when I
> overcame the mental block of what you could do with writing to 'read
> only' methods.  I know I was one of the people who suggested that those
> methods be read only - in retrospect I think that was a big mistake, and
> I have regretted it ever since I broke through that mental block.


> I would suggest making them _all_ read write  :)  You can do so much
> cool stuff with the API, and I'd rather see it break because someone was
> pushing the limits, rather than having to say "we don't allow that
> because it might break".
> my $0.02, for what it's worth :)

appreciated :)

some of those fields, though, are really messy.  for example,
per_dir_config is an internal httpd configuration vector, so to set it
properly we'd probably need a whole new typemap entry.  and there's no
reason you'd ever want to mess with it since we have an interface to all
the custom config stuff already.  similar for something like write
access to a $r->pool - that's just no good no matter how you look at it :)

I think making logical things like header_only or request_line writable
is good for subverting when we know better, but that's because they
represent attributes of the request we'd be interested in faking.
making something like $r->next() writable makes far less sense, since it
represents private httpd bookkeeping that could have core-dump like effects.

things like $r->server() or $r->connection() would be ok, but you'd
really want to set those to your own subclass I'd think, not things at
random.  I'd have to mull that one over.

anyway, for the fields I've mentioned, making them writable is just
flicking the appropriate flag in (see
ModPerl::MapUtil for an explanation) and I guess adding some basic tests
to make sure things don't blow up when you try to write to them.

low-hanging fruit :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message