Re: help on setting up a PerlFixupHandler
On Wednesday 06 August 2003 18:29, Geoffrey Young wrote:
> > sub handler {
> > my $r = shift;
> >
> > return DECLINED if $r->content_type ne 'text/html';
> > return SERVER_ERROR unless $r->can_stack_handlers;
> >
> > $r->set_handlers(PerlHandler => ['ContentHandler']);
> >
> > return OK;
> > }
> >
> > What am I missing?
>
> unlike the other phases of the request cycle, for the content phase
> you need to do two things - tell apache that mod_perl is in charge,
> and tell mod_perl which Perl handler it should use. you've done the
> latter. for the former, use $r->handler('perl-script'), which is
> analogous to SetHandler perl-script that you would ordinarily see for
> a mod_perl setup.
Thank you!
I tried to add that line to the Dispatcher:
package Dispatcher;
use Apache::Constants ':common';
sub handler {
my $r = shift;
return DECLINED if $r->content_type ne 'text/html';
return SERVER_ERROR unless $r->can_stack_handlers;
$r->handler('perl-script');
$r->set_handlers(PerlHandler => ['ContentHandler']);
return OK;
}
1;
without luck however, keeps on looking under the document root
for /admin. Should that change be enough?
-- fxn
Re: help on setting up a PerlFixupHandler
[EMAIL PROTECTED] wrote:
It seems to me that $r->content-type is for what your server sends to the
client, which is probably undef in the Fixup stage, where you test it.
You probaly meant to test for the
$ct = $r->header_in("Content-type")
if you wanted to see whats requested from the client.
But then, there are examples in the books that use that method that way.
For instance, in recipe 14.1 of the Cookbook, which is about how to
disable a configured mod_perl PerlHandler, the "Technique" section says:
Set the handler back to the default Apache content handler from a
PerlFixupHandler.
# Only run the PerlHandler for HTML.
# For everything else, run the default Apache content handler.
$r->handler('default-handler') unless $r->content_type eq 'text/html';
I think in the Eagle book there is some code like that as well, cannot
check it right now however.
So, looks like that test makes sense, or can make sense, in that handler.
-- fxn
RE: help on setting up a PerlFixupHandler
Hi,
It seems to me that $r->content-type is for what your server sends to the
client, which is probably undef in the Fixup stage, where you test it.
You probaly meant to test for the
$ct = $r->header_in("Content-type")
if you wanted to see whats requested from the client.
Anyway, as Christopher pointed out you can get the "what's before" load off
your shoulders ;-)
HTH,
Lian Sebe, M.Sc.
Freelance Analyst-Programmer
www.programEz.net
> -Original Message-
> From: Xavier Noria [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 06, 2003 9:40 PM
> To: [EMAIL PROTECTED]
> Subject: Re: help on setting up a PerlFixupHandler
>
>
> On Wednesday 06 August 2003 20:26, Christopher Grau wrote:
>
> > On Wed, Aug 06, 2003 at 08:24:30PM +0200, Xavier Noria wrote:
> > > To fix that, is it safe to change the test to
> > >
> > > defined $r->content_type and $r->content_type ne 'text/html';
> > >
> > > or is there a better way?
> >
> > I usually don't concern myself with the previous content type when
> > writing -based content handlers. My output is always
> > "text/html" anyway. Would it be safe in your application to just
> > leave it out completely?
>
> Hmmm, you are right, now that I think about it /admin will only
> serve HTML and since I don't understand that undef I'll remove
> that line altogether, the "test" is performed by anyway.
>
> Now that I understand what happens I will try to figure out in the
> docs when $r->content_type returns something.
>
> Thank you very much to all, I was somewhat stuck with this.
>
> -- fxn
>
Re: help on setting up a PerlFixupHandler
On Wed, Aug 06, 2003 at 07:41:20PM +0200, Xavier Noria wrote:
> package Dispatcher;
>
> use Apache::Constants ':common';
>
> sub handler {
> my $r = shift;
>
> return DECLINED if $r->content_type ne 'text/html';
> return SERVER_ERROR unless $r->can_stack_handlers;
>
> $r->handler('perl-script');
> $r->set_handlers(PerlHandler => ['ContentHandler']);
>
> return OK;
> }
>
> 1;
>
> without luck however, keeps on looking under the document root
> for /admin. Should that change be enough?
Are you sure the content-type is "text/html"? Since you have your own
handler, Apache is probably using the value from the
DefaultType directive which, I think, defaults to "text/plain" when Apache
is installed.
-chris
RE: help on setting up a PerlFixupHandler
Hi Geoffrey & Xavier,
I don't argue on the fact the Content-type is an entity header available in
both situations. However I'm talking about how to get/set in mod_perl the
Content-type in those 2 situations, which according to the mod_perl 1.0 API
docs and as I understand it, are different animals:
>>>>
1.7.8 $r->content_type( [$newval] )
Get or set the content type being sent to the client. Content types are
strings like "text/plain",
"text/html" or "image/gif". This corresponds to the "Content-Type" header in
the HTTP
protocol. Example of usage is:
$previous_type = $r->content_type;
$r->content_type("text/plain");
>>>>
...
>>>>
1.5.16 $r->header_in( $header_name, [$value] )
Return the value of a client header. Can be used like this:
$ct = $r->header_in("Content-type");
>>>>>>>
So, while I'm not 100% sure about this, logically the $r->content_type
should be empty before the response is prepared to be sent to the browser,
so it should be empty in the Fixup stage.
In fact what I miss (and I guess I'm not alone ;-) is a documentation that
would take the $r from the "newly born" state and describe what's
added/deleted to it during a full process loop, at each stage.
Besides I'd like to know about each major optional module (like mod_rewrite,
mod_ssl, etc) where they intervine in the loop and what they read/or set.
Most of these one can guess but I'm not aware of such a documentation.
Regards,
Lian Sebe, M.Sc.
Freelance Analyst-Programmer
www.programEz.net
> -Original Message-
> From: Geoffrey Young [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 07, 2003 5:36 AM
> To: Xavier Noria
> Cc: [EMAIL PROTECTED]
> Subject: Re: help on setting up a PerlFixupHandler
>
>
>
>
> Xavier Noria wrote:
> > [EMAIL PROTECTED] wrote:
> >
> >> It seems to me that $r->content-type is for what your server
> sends to the
> >> client, which is probably undef in the Fixup stage, where you test it.
> >>
> >> You probaly meant to test for the
> >> $ct = $r->header_in("Content-type")
> >> if you wanted to see whats requested from the client.
>
> Content-Type is an entity header, so it can apply to both incoming and
> outgoing headers. however, it's more generally seen as an
> outgoing header
> for normal web activity, leaving headers_in empty.
>
> >
> >
> > But then, there are examples in the books that use that method that way.
> >
> > For instance, in recipe 14.1 of the Cookbook, which is about how to
> > disable a configured mod_perl PerlHandler, the "Technique" section says:
> >
> > Set the handler back to the default Apache content handler from a
> > PerlFixupHandler.
> >
> > # Only run the PerlHandler for HTML.
> > # For everything else, run the default Apache content handler.
> > $r->handler('default-handler') unless $r->content_type eq 'text/html';
> >
> > I think in the Eagle book there is some code like that as well, cannot
> > check it right now however.
> >
> > So, looks like that test makes sense, or can make sense, in
> that handler.
>
> $r->content_type is generally set by mod_mime, during the
> mime-type phase,
> according to it's rules. for most setups, it should be set to
> something by
> fixup, but I guess it's dependent on your particular settings.
>
> --Geoff
>
Re: help on setting up a PerlFixupHandler
So, while I'm not 100% sure about this, logically the $r->content_type
should be empty before the response is prepared to be sent to the browser,
so it should be empty in the Fixup stage.
not necessarily.
if you request index.html, mod_mime (at the mime-type phase) will set the
content type to text/html based on the file extension. mod_mime_magic will
do the same, but by analyzing the contents of the file.
if you are generating dynamic content and there is no file type to examine
(or consistently relate, as .cgi can produce multiple CTs), no default type,
and no file to examine, then there is no way the mime modules can set a
content type. the end result would be undef in fixup and beyond.
In fact what I miss (and I guess I'm not alone ;-) is a documentation that
would take the $r from the "newly born" state and describe what's
added/deleted to it during a full process loop, at each stage.
there is lots of documentation on this kind of thing, but nothing specific
like "$r->content_type is set during the mime-type phase" because things
like this are dependent on varying circumstances.
Part III of the mod_perl Developer's Cookbook talks about the each phase of
the request cycle in depth. you can read part of it from
http://www.modperlcookbook.org/. the eagle book also covers it.
Besides I'd like to know about each major optional module (like mod_rewrite,
mod_ssl, etc) where they intervine in the loop and what they read/or set.
Most of these one can guess but I'm not aware of such a documentation.
that's complex. for instance, mod_rewrite can enter just about every part
of the request cycle, depending on how it's configured.
the way to discover this is to look at the code (remember, it's open :) - at
the end of each extension module is the place where hooks are typically
registered. look for a line such as
module MODULE_VAR_EXPORT rewrite_module = {
which begins the list of phases the module hooks into.
HTH
--Geoff
RE: help on setting up a PerlFixupHandler
Well, thank you very much for the references.
I guess I'll have to skip next few pints and finally get that book I've
heard so much about ;-)
Lian Sebe, M.Sc.
Freelance Analyst-Programmer
www.programEz.net
> -Original Message-
> From: Geoffrey Young [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 07, 2003 3:15 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: help on setting up a PerlFixupHandler
>
>
>
> >
> > So, while I'm not 100% sure about this, logically the $r->content_type
> > should be empty before the response is prepared to be sent to
> the browser,
> > so it should be empty in the Fixup stage.
>
> not necessarily.
>
> if you request index.html, mod_mime (at the mime-type phase) will set the
> content type to text/html based on the file extension.
> mod_mime_magic will
> do the same, but by analyzing the contents of the file.
>
> if you are generating dynamic content and there is no file type
> to examine
> (or consistently relate, as .cgi can produce multiple CTs), no
> default type,
> and no file to examine, then there is no way the mime modules can set a
> content type. the end result would be undef in fixup and beyond.
>
> >
> > In fact what I miss (and I guess I'm not alone ;-) is a
> documentation that
> > would take the $r from the "newly born" state and describe what's
> > added/deleted to it during a full process loop, at each stage.
>
> there is lots of documentation on this kind of thing, but nothing
> specific
> like "$r->content_type is set during the mime-type phase" because things
> like this are dependent on varying circumstances.
>
> Part III of the mod_perl Developer's Cookbook talks about the
> each phase of
> the request cycle in depth. you can read part of it from
> http://www.modperlcookbook.org/. the eagle book also covers it.
>
> > Besides I'd like to know about each major optional module (like
> mod_rewrite,
> > mod_ssl, etc) where they intervine in the loop and what they
> read/or set.
> > Most of these one can guess but I'm not aware of such a documentation.
>
> that's complex. for instance, mod_rewrite can enter just about
> every part
> of the request cycle, depending on how it's configured.
>
> the way to discover this is to look at the code (remember, it's
> open :) - at
> the end of each extension module is the place where hooks are typically
> registered. look for a line such as
>
> module MODULE_VAR_EXPORT rewrite_module = {
>
> which begins the list of phases the module hooks into.
>
> HTH
>
> --Geoff
>
>
Re: help on setting up a PerlFixupHandler
Xavier Noria wrote:
[EMAIL PROTECTED] wrote:
It seems to me that $r->content-type is for what your server sends to the
client, which is probably undef in the Fixup stage, where you test it.
You probaly meant to test for the
$ct = $r->header_in("Content-type")
if you wanted to see whats requested from the client.
Content-Type is an entity header, so it can apply to both incoming and
outgoing headers. however, it's more generally seen as an outgoing header
for normal web activity, leaving headers_in empty.
But then, there are examples in the books that use that method that way.
For instance, in recipe 14.1 of the Cookbook, which is about how to
disable a configured mod_perl PerlHandler, the "Technique" section says:
Set the handler back to the default Apache content handler from a
PerlFixupHandler.
# Only run the PerlHandler for HTML.
# For everything else, run the default Apache content handler.
$r->handler('default-handler') unless $r->content_type eq 'text/html';
I think in the Eagle book there is some code like that as well, cannot
check it right now however.
So, looks like that test makes sense, or can make sense, in that handler.
$r->content_type is generally set by mod_mime, during the mime-type phase,
according to it's rules. for most setups, it should be set to something by
fixup, but I guess it's dependent on your particular settings.
--Geoff
Re: help on setting up a PerlFixupHandler
sub handler {
my $r = shift;
return DECLINED if $r->content_type ne 'text/html';
return SERVER_ERROR unless $r->can_stack_handlers;
$r->set_handlers(PerlHandler => ['ContentHandler']);
return OK;
}
What am I missing?
unlike the other phases of the request cycle, for the content phase you need
to do two things - tell apache that mod_perl is in charge, and tell mod_perl
which Perl handler it should use. you've done the latter. for the former,
use $r->handler('perl-script'), which is analogous to SetHandler perl-script
that you would ordinarily see for a mod_perl setup.
HTH
--Geoff
Re: help on setting up a PerlFixupHandler
On Wednesday 06 August 2003 20:26, Christopher Grau wrote: > On Wed, Aug 06, 2003 at 08:24:30PM +0200, Xavier Noria wrote: > > To fix that, is it safe to change the test to > > > > defined $r->content_type and $r->content_type ne 'text/html'; > > > > or is there a better way? > > I usually don't concern myself with the previous content type when > writing -based content handlers. My output is always > "text/html" anyway. Would it be safe in your application to just > leave it out completely? Hmmm, you are right, now that I think about it /admin will only serve HTML and since I don't understand that undef I'll remove that line altogether, the "test" is performed by anyway. Now that I understand what happens I will try to figure out in the docs when $r->content_type returns something. Thank you very much to all, I was somewhat stuck with this. -- fxn
Re: help on setting up a PerlFixupHandler
On Wed, Aug 06, 2003 at 08:24:30PM +0200, Xavier Noria wrote: > To fix that, is it safe to change the test to > > defined $r->content_type and $r->content_type ne 'text/html'; > > or is there a better way? I usually don't concern myself with the previous content type when writing -based content handlers. My output is always "text/html" anyway. Would it be safe in your application to just leave it out completely? -chris
Re: help on setting up a PerlFixupHandler
On Wednesday 06 August 2003 19:53, Christopher Grau wrote: > Are you sure the content-type is "text/html"? Since you have your > own handler, Apache is probably using the value from the > DefaultType directive which, I think, defaults to "text/plain" when > Apache is installed. That's it, $r->content_type ne 'text/html'; succeeds because $r->content_type is undef, so we return DECLINED and the default content handler is run AFAICT. DefaultType is text/plain in httpd.conf, why that method returns undef? To fix that, is it safe to change the test to defined $r->content_type and $r->content_type ne 'text/html'; or is there a better way? -- fxn
