PROPOSAL: Enhance mod_headers as a debug/test tool

[Nick Kew <ni...@webthing.com>]

(If this gets the thumbs up, I'll be happy to do the work:-)

In testing new code, it's often helpful to simulate different
browser requests, and responses.

For handlers and filters, mod_headers enables us to set up testcases
very easily, with the Header and (especially) RequestHeader directives.
But that's in a fixups hook, so it's no use for any hooks running in
earlier phases of a request.

My proposal is to introduce an additional DEBUG keyword to the
Header and RequestHeader directives.  Headers marked as DEBUG will
be set in post_read_request, so they are available to other modules.
Without DEBUG, it will default to current (fixups) behaviour.

Of course, DEBUG won't work with conditional (Request)Header directives.
In addition to documenting this, attempts to do so will log a warning.

-- 
Nick Kew

Re: PROPOSAL: Enhance mod_headers as a debug/test tool

[Joshua Slive <jo...@slive.ca>]

On Sun, 4 Jul 2004, [ISO-8859-15] André Malo wrote:
> > My proposal is to introduce an additional DEBUG keyword to the
> > Header and RequestHeader directives.  Headers marked as DEBUG will
> > be set in post_read_request, so they are available to other modules.
> > Without DEBUG, it will default to current (fixups) behaviour.
> >
> > Of course, DEBUG won't work with conditional (Request)Header directives.
> > In addition to documenting this, attempts to do so will log a warning.
>
> Sounds like a good tool. comments from me:
>
> - I would not call it DEBUG, but "early" or "setearly" or the like

I agree. Note that if you add this, people will use it for things other
than debugging.  For example, there are frequently requests to do silly
things like ignore the client's Accept header.

> - I'd just replace the env clause with that keyword (i.e. mutual exlusion)
> - post_read_request is *really* early. So these directives would be only valid
> in server context / virtual host.

Of course, for these reasons, people won't be able to do as much mangling
as they want.  So this feature would need to be carefully documented.

Joshua.

Re: PROPOSAL: Enhance mod_headers as a debug/test tool

[André Malo <nd...@perlig.de>]

* Nick Kew <ni...@webthing.com> wrote:

> (If this gets the thumbs up, I'll be happy to do the work:-)
> 
> In testing new code, it's often helpful to simulate different
> browser requests, and responses.
> 
> For handlers and filters, mod_headers enables us to set up testcases
> very easily, with the Header and (especially) RequestHeader directives.
> But that's in a fixups hook, so it's no use for any hooks running in
> earlier phases of a request.
> 
> My proposal is to introduce an additional DEBUG keyword to the
> Header and RequestHeader directives.  Headers marked as DEBUG will
> be set in post_read_request, so they are available to other modules.
> Without DEBUG, it will default to current (fixups) behaviour.
> 
> Of course, DEBUG won't work with conditional (Request)Header directives.
> In addition to documenting this, attempts to do so will log a warning.

Sounds like a good tool. comments from me:

- I would not call it DEBUG, but "early" or "setearly" or the like
- I'd just replace the env clause with that keyword (i.e. mutual exlusion)
- post_read_request is *really* early. So these directives would be only valid
in server context / virtual host.

nd
-- 
die (eval q-qq:Just Another Perl Hacker
:-)

# André Malo, <http://pub.perlig.de/> #

Re: PROPOSAL: Enhance mod_headers as a debug/test tool

[André Malo <nd...@perlig.de>]

* Dirk-Willem van Gulik <di...@webweaving.org> wrote:

> +1 for something like this - as I've had to manually hack things like this
> in more than once to wack something like a broken Oracle/Orian SSO back in
> line. However please make it general and either add it as a second
> directive or have something like
> 
> 	Header [ inbound | outbound ] <set|append|add>  header value
> 	ErrorHeader ..
> 
> where the default is outbound. If you are really going to do this - I'd
> love to also have added:
> 
> 	RequestHeader [ inbound | outbound ] <set|append|add>  header value

Ah, ErrorHeader doesn't exist anymore. What is inbound/outbound if not the
Header/RequestHeader distinction?

nd

Re: PROPOSAL: Enhance mod_headers as a debug/test tool

[Dirk-Willem van Gulik <di...@webweaving.org>]

On Sun, 4 Jul 2004, Nick Kew wrote:

> very easily, with the Header and (especially) RequestHeader directives.
> But that's in a fixups hook, so it's no use for any hooks running in
...
> Header and RequestHeader directives.  Headers marked as DEBUG will
> be set in post_read_request, so they are available to other modules.
> Without DEBUG, it will default to current (fixups) behaviour.

+1 for something like this - as I've had to manually hack things like this
in more than once to wack something like a broken Oracle/Orian SSO back in
line. However please make it general and either add it as a second
directive or have something like


	Header [ inbound | outbound ] <set|append|add>  header value
	ErrorHeader ..

where the default is outbound. If you are really going to do this - I'd
love to also have added:

	RequestHeader [ inbound | outbound ] <set|append|add>  header value

so I can muck around with the request to fool some php/java backend to
which I do not have sufficient access to hack it in there (say because it
is some broken commercial product).

Dw.

Re: PROPOSAL: Enhance mod_headers as a debug/test tool

[Nick Kew <ni...@webthing.com>]

On Sun, 4 Jul 2004, Nick Kew wrote:

> (If this gets the thumbs up, I'll be happy to do the work:-)

Since reaction seemed broadly positive, I've checked it in to HEAD.

Following suggestions in the replies, it's invoked by the keyword
"early" which takes the place of the env clause.

-- 
Nick Kew