You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/01/07 06:21:56 UTC
Re: [mp2] non-parsed headers registry scripts
Geoffrey Young wrote:
>
>
> Stas Bekman wrote:
>
>> Geoffrey Young wrote:
>>
>>>
>>>> Moreover if you look at mod_cgi.c:818, if the script's name starts
>>>> with 'nph-' it'll cheat at internally remove all the protocol
>>>> filters which mess with headers letting the script do its own thing.
>>>
>>>
>>>
>>>
>>> ugh
>>
>>
>>
>> If assbackwards is the designed solution for non-parsed headers, I
>> wonder why mod_cgi doesn't use it. May be to optimize things?
>
>
> perhaps. or perhaps assbackwards isn't really all that designed (as in
> a designed public API :)
>
>
>>> sure. just remember that that only supresses outgoing headers - it
>>> doesn't do anything to incoming headers or make the outgoing ones
>>> invisible. I'm never sure exactly what nph scripts do, but if there
>>> is more to the mod_cgi implementation than supressing outgoing
>>> headers we probably need to evaluate exactly what it is first.
>>
>>
>>
>> It looks that's what mod_cgi does. We could do the same as mod_cgi
>> instead of setting assbackwards. May be we should ask at httpd-dev?
>>
>
> well, I haven't looked at the mod_cgi code yet, but if the end result
> for nph scripts is the same as merely setting r->assbackwards = 1, then
> yes, I'd be interested in hearing what httpd-dev has so say about the
> different approaches.
>
> maybe you'll even get an answer ;)
So I didn't get any answers.
I'm still not sure what's the best option:
1) add a new option: PerlOptions +NonParseHeaders
2) /nph-/ in registrycooker
in either case call $r->assbackwards(1);
The reason I don't like (1) is that it adds a (tiny) overhead which is totally
unnecessary for 99.9999% of handlers, which can call $r->assbackwards(1) if
they need to. It's only registry scripts that need to run under mod_cgi that
need to emulate mod_cgi, therefore (2) seems to be the simplest solution. or
we can even add ModPerl::RegistryNPH which will just call $r->assbackwards(1);
for those special cases.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] non-parsed headers registry scripts
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> mod_perl doesn't send headers anymore - the header filter in apache 2
>> core
>> does that now. there is no $r->send_http_header() method.
>
>
> So does the header filter send out heaers if I don't ask it to?
yes, headers are _always_ sent unless r->assbackwards is true (or there was
a filter error it seems). ap_http_header_filter is defined in
http_protocol.c and registered in http_core.c, if you're interested.
> You're right, mod_perl is not the place to fix this. I should be
> compaining to the core apache team about it if I want it changed. It's
> just a shame because this was obviously meant to be used internally only
> and now it's a confusing and amateurish part of the public API.
:)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] non-parsed headers registry scripts
Posted by Stas Bekman <st...@stason.org>.
As there were no further follow ups, I've committed the suggested
implementation. Lemme know if anything is wrong with it.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] non-parsed headers registry scripts
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
[...]
>>> the reason I suggested a subclass was so that the rare people who
>>> require nph scripts have an outlet, while the vast majority of users
>>> are not
>>> burdened with the overhead of checking for nph- scripts on every
>>> request.
>>
>>
>>
>> A quick index() call to check for "nph-" is not going to matter in any
>> real world scenario.
>
>
> OK, so it seems that we agree on having the support only for /^nph-/ in
> registry. Now we just need to decide whether we
> 1) support this by default for any registry class, unless explicitly
> overriden in the subclass,
> 2) or introduce a new subclass just for that purpose.
>
> The problem with (2) is that if you need mix and match nph- and not nph-
> scripts living in the same dir you will need to duplicate configs.
>
> I'm fine going with (1) since we can always do (2) at a later stage.
so here is the implementation of (1) plus tests.
Index: ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v
retrieving revision 1.40
diff -u -u -r1.40 RegistryCooker.pm
--- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 19 Dec 2003 06:32:28 -0000 1.40
+++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 21 Jan 2004 06:38:21 -0000
@@ -25,6 +25,7 @@
use ModPerl::Global ();
use File::Spec::Functions ();
+use File::Basename;
use Apache::Const -compile => qw(:common &OPT_EXECCGI);
@@ -360,6 +361,11 @@
$self->strip_end_data_segment;
+ # handle the non-parsed handlers ala mod_cgi (though mod_cgi does
+ # some tricks removing the header_out and other filters, here we
+ # just call assbackwards which has the same effect).
+ my $base = File::Basename::basename($self->{FILENAME});
+ my $nph = substr($base, 0, 4) eq 'nph-' ? '$_[0]->assbackwards(1);' : "";
my $script_name = $self->get_script_name || $0;
my $eval = join '',
@@ -367,6 +373,7 @@
$self->{PACKAGE}, ";",
"sub handler {",
"local \$0 = '$script_name';",
+ $nph,
$line,
${ $self->{CODE} },
"\n}"; # last line comment without newline?
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ ModPerl-Registry/t/nph.t 2004-01-20 22:29:55.000000000 -0800
@@ -0,0 +1,54 @@
+use strict;
+use warnings FATAL => 'all';
+
+use Apache::Test;
+use Apache::TestUtil;
+use Apache::TestRequest;
+
+plan tests => 6;
+
+my $url = "/nph/nph-foo.pl";
+
+my %expected = (
+ code => '250',
+ body => "non-parsed headers body",
+ headers => {
+ 'content-type' => 'text/text',
+ 'pragma' => 'no-cache',
+ 'cache-control' => 'must-revalidate, no-cache, no-store',
+ 'expires' => '-1',
+ },
+);
+
+my $res = GET $url;
+
+my %received = (
+ code => $res->code,
+ body => $res->content,
+ headers => $res->headers, # LWP lc's the headers
+);
+
+use Data::Dumper;
+print Dumper $res->headers;
+
+for my $key (keys %expected) {
+ my $expected = $expected{$key};
+ my $received = $received{$key};
+ if ($key eq 'headers') {
+ for my $header (keys %$expected) {
+ ok t_cmp(
+ $expected->{$header},
+ $received->{$header},
+ "test header $header"
+ );
+ }
+ }
+ else {
+ ok t_cmp(
+ $expected,
+ $received,
+ "test key: $key"
+ );
+ }
+}
+
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ ModPerl-Registry/t/cgi-bin/nph-foo.pl 2004-01-20 22:36:55.000000000 -0800
@@ -0,0 +1,13 @@
+#!/usr/bin/perl -w
+
+my $r = shift;
+
+print "HTTP/1.0 250 Pretty OK\r\n";
+print join("\n",
+ 'Content-type: text/text',
+ 'Pragma: no-cache',
+ 'Cache-control: must-revalidate, no-cache, no-store',
+ 'Expires: -1',
+ "\n");
+
+print "non-parsed headers body";
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] non-parsed headers registry scripts
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> Geoffrey Young wrote:
>>Does mod_cgi still look for /nph-/ in script names?
>
> stas said so in a previous message, IIRC. I haven't looked.
modules/generators/mod_cgi.c: nph = !(strncmp(argv0, "nph-", 4));
>> what's the real goal with registry - to provide
>> 100% compat with mod_cgi or to make mod_cgi-like scripts run as fast
>> as they
>> can?
>
>
> I think definitely the former. People who are really concerned about
> performance should not be using Registry.
I agree with Perrin on this.
>> the reason I suggested a subclass was so that the rare people who
>> require nph scripts have an outlet, while the vast majority of users
>> are not
>> burdened with the overhead of checking for nph- scripts on every request.
>
>
> A quick index() call to check for "nph-" is not going to matter in any
> real world scenario.
OK, so it seems that we agree on having the support only for /^nph-/ in
registry. Now we just need to decide whether we
1) support this by default for any registry class, unless explicitly overriden
in the subclass,
2) or introduce a new subclass just for that purpose.
The problem with (2) is that if you need mix and match nph- and not nph-
scripts living in the same dir you will need to duplicate configs.
I'm fine going with (1) since we can always do (2) at a later stage.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] non-parsed headers registry scripts
Posted by Perrin Harkins <pe...@elem.com>.
Geoffrey Young wrote:
> I go back and forth on this issue. while Registry comes close to emulating
> mod_cgi, the point I waver on is whether we really should bill it as a
> drop-in replacement
That is how people try to use it. The less they have to change their
code, the better.
> what's the real goal with registry - to provide
> 100% compat with mod_cgi or to make mod_cgi-like scripts run as fast as they
> can?
I think definitely the former. People who are really concerned about
performance should not be using Registry.
> the reason I suggested a subclass was so that the rare people who
> require nph scripts have an outlet, while the vast majority of users are not
> burdened with the overhead of checking for nph- scripts on every request.
A quick index() call to check for "nph-" is not going to matter in any
real world scenario.
> mod_perl doesn't send headers anymore - the header filter in apache 2 core
> does that now. there is no $r->send_http_header() method.
So does the header filter send out heaers if I don't ask it to?
> one I do feel strongly about. however insane it is to have a public
> assbackwards() API, mod_perl should just be offering up the Apache API as it
> is and getting out of the way. that's what it's called in the Apache API,
> so $r->assbackwards needs to stay.
You're right, mod_perl is not the place to fix this. I should be
compaining to the core apache team about it if I want it changed. It's
just a shame because this was obviously meant to be used internally only
and now it's a confusing and amateurish part of the public API.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] non-parsed headers registry scripts
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I actually think that since Registry exists to be backwards compatible
> with mod_cgi, it should emulate mod_cgi as closely as it can, including
> the nph support.
I go back and forth on this issue. while Registry comes close to emulating
mod_cgi, the point I waver on is whether we really should bill it as a
drop-in replacement - in the history of Registry, I honestly doubt if there
has been a single user that really was able to 'drop-in' a mod_cgi script
and have it work without alteration. well, ok, maybe that's an exaggeration :)
> Does mod_cgi still look for /nph-/ in script names?
stas said so in a previous message, IIRC. I haven't looked.
> If
> so, Registry should do it too.
that's where I'm not sure. what's the real goal with registry - to provide
100% compat with mod_cgi or to make mod_cgi-like scripts run as fast as they
can? the reason I suggested a subclass was so that the rare people who
require nph scripts have an outlet, while the vast majority of users are not
burdened with the overhead of checking for nph- scripts on every request.
at least that's my thought today. as I said, I tend to change my view every
few months :)
>
> Am I correct in thinking that this is not an issue at all if you are not
> using Registry, i.e. mod_perl will not send out any automatic headers if
> you don't ask it to?
mod_perl doesn't send headers anymore - the header filter in apache 2 core
does that now. there is no $r->send_http_header() method.
>
> I'd really prefer to have a better name for assbackwards if it's going
> to be used as a public API. Maybe we could make an alias for it that
> explains its purpose more clearly.
this one I do feel strongly about. however insane it is to have a public
assbackwards() API, mod_perl should just be offering up the Apache API as it
is and getting out of the way. that's what it's called in the Apache API,
so $r->assbackwards needs to stay.
if you feel strongly about an alias, I guess we can do that, but I wouldn't
want a user to try accessing a part of the request_rec by name and have it
not be there.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] non-parsed headers registry scripts
Posted by Perrin Harkins <pe...@elem.com>.
Stas Bekman wrote:
>> I think I'd prefer the new subclass over adding nph support to
>> Registry.pm.
>
>
> Sounds like a good choice to me. Or may be we should introduce registry
> options (e.g. via simple dir_config or a new directive).
I actually think that since Registry exists to be backwards compatible
with mod_cgi, it should emulate mod_cgi as closely as it can, including
the nph support. Does mod_cgi still look for /nph-/ in script names?
If so, Registry should do it too.
Am I correct in thinking that this is not an issue at all if you are not
using Registry, i.e. mod_perl will not send out any automatic headers if
you don't ask it to?
I'd really prefer to have a better name for assbackwards if it's going
to be used as a public API. Maybe we could make an alias for it that
explains its purpose more clearly.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] non-parsed headers registry scripts
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>I'm still not sure what's the best option:
>> 1) add a new option: PerlOptions +NonParseHeaders
>> 2) /nph-/ in registrycooker
>>in either case call $r->assbackwards(1);
>>
>>The reason I don't like (1) is that it adds a (tiny) overhead which is
>>totally unnecessary for 99.9999% of handlers,
>
>
> you mean each new option adds more request-time overhead?
Yes. Very tiny though. And it adds to the code clutter.
>>which can call
>>$r->assbackwards(1) if they need to. It's only registry scripts that
>>need to run under mod_cgi that need to emulate mod_cgi, therefore (2)
>>seems to be the simplest solution. or we can even add
>>ModPerl::RegistryNPH which will just call $r->assbackwards(1); for
>>those special cases.
>
>
> I think I'd prefer the new subclass over adding nph support to Registry.pm.
Sounds like a good choice to me. Or may be we should introduce registry
options (e.g. via simple dir_config or a new directive). It'll add a slight
overhead to registry though. I'm just not sure we want to add a whole bunch of
subclasses to ModPerl-Registry.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] non-parsed headers registry scripts
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I'm still not sure what's the best option:
> 1) add a new option: PerlOptions +NonParseHeaders
> 2) /nph-/ in registrycooker
> in either case call $r->assbackwards(1);
>
> The reason I don't like (1) is that it adds a (tiny) overhead which is
> totally unnecessary for 99.9999% of handlers,
you mean each new option adds more request-time overhead?
> which can call
> $r->assbackwards(1) if they need to. It's only registry scripts that
> need to run under mod_cgi that need to emulate mod_cgi, therefore (2)
> seems to be the simplest solution. or we can even add
> ModPerl::RegistryNPH which will just call $r->assbackwards(1); for
> those special cases.
I think I'd prefer the new subclass over adding nph support to Registry.pm.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org