You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@gmail.com> on 2004/12/14 04:26:58 UTC
mod_actions 1.32 patch never made it to 2.0
A co-worker of mine pointed out that the following works in Apache
1.3, but not 2.0 if the location /foo, doesn't exist on the disk:
AddHandler foobar /cgi-bin/printenv
<Location /foo>
SetHandler foobar
</Location>
This patch ports this behavior forward into 2.0.
Index: modules/mappers/mod_actions.c
===================================================================
--- modules/mappers/mod_actions.c (revision 111773)
+++ modules/mappers/mod_actions.c (working copy)
@@ -163,11 +163,6 @@
if ((t = apr_table_get(conf->action_types,
action ? action : ap_default_type(r)))) {
script = t;
- if (r->finfo.filetype == 0) {
- ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
- "File does not exist: %s", r->filename);
- return HTTP_NOT_FOUND;
- }
}
if (script == NULL)
I'm not subscribed to the list anymore, but please let me know when
this is committed.
Ryan
--
Ryan Bloom
rbb@apache.org
rbb@redhat.com
rbloom@gmail.com
Re: mod_actions 1.32 patch never made it to 2.0
Posted by Joshua Slive <jo...@slive.ca>.
André Malo wrote:
> * Cliff Woolley wrote:
>
>
>>So why is this same general behavior unconditional in httpd 1.3 but
>>non-existant in 2.0 and requires a "virtual" flag on 2.1? Andre?
>>Thoughts? The "virtual" thing was your doing...
>
>
> see STATUS file. It's already voted for backport, just didn't make it yet...
>
> The reason for the virtual flag is that it should be a user decision whether
> the httpd should generate the 404 (with errordocument and all) or not. IMHO
> the unconditional behaviour in 1.3 was a mistake (made in version 1.3.10).
> 2.x was forked in 1.3.9 :-)
I agree. Action was designed to enable processing files via CGI
scripts, not to handle arbitrary URLs.
Ryan's example (and most others that want this behavior) would be more
cleanly handled with a simple
ScriptAlias /foo /full/path/to/cgi-bin/printenv
Joshua.
Re: mod_actions 1.32 patch never made it to 2.0
Posted by André Malo <nd...@perlig.de>.
* Ryan Bloom wrote:
> > > I'm sorry, but no it is not. I know something about this, and we
> > > spent a lot of time and energy trying to ensure that a config that
> > > worked in 1.3 worked the same way in 2.0.
> >
> > Well, you had no luck, it seems.
>
> That's just not true. 90% of the directives in Apache 1.3 did not
> change their meaning in the port to 2.0.
There are so much subtle differences. E.g. DirectoryIndex works slightly
different, causing many problems (with handlers in <Location>, with
RewriteRules etc.)
But anyway, you've convinced me somehow. What about the following
suggestion:
We take the new flag and give it two possible values 'virtual' and
'physical' (or so), making virtual default.
That way it's consistent with 1.3 (though not with previous 2.0 releases!)
and even consistent in itself.
Opinions?
nd
--
s s^saaaaaoaaaoaaaaooooaaoaaaomaaaa a alataa aaoat a a
a maoaa a laoata a oia a o a m a o alaoooat aaool aaoaa
matooololaaatoto aaa o a o ms;s;\s;s;g;y;s;:;s;y#mailto: #
\51/\134\137| http://www.perlig.de #;print;# > nd@perlig.de
Re: mod_actions 1.32 patch never made it to 2.0
Posted by André Malo <nd...@apache.org>.
* Ryan Bloom <rb...@gmail.com> wrote:
> On Tue, 14 Dec 2004 17:13:23 +0100, André Malo <nd...@apache.org> wrote:
> > * Ryan Bloom <rb...@gmail.com> wrote:
> >
> > > I have a couple of pretty big issues with this response.
> > >
> > > 1) You have a configuration in Apache 1.3 that doesn't work in Apache
> > > 2.0, but the config directives don't have to be changed at all. This
> > > is something that we worked really hard not to do in 2.0. There
> > > should never be a config in 1.3 that just gives the wrong results in
> > > 2.0 without any way for the user to understand why.
> >
> > Ah? That's what one would call a bug. While breaking the behaviour in
> > 1.3.9/1.3.10 nobody even thought about this issue. It's *still not
> > documented that it was broken*. And a lot of users suffered of it,
> > including me.
>
> Suffered how? How exactly did a change that made the code accept more
> configs break your config? Also, it isn't that nobody thought of this
> when making the change to 1.3. Looking through the mailing list
> archives, I see Ben Laurie specifically had a problem with Location
> and mod_actions that Manoj fixed. I haven't found the whole thread
> about the problem, just the RM notes about it. So, we have a bug that
> was fixed in 1.3 that was reintroduced in 2.0, and 2.0 is solving the
> problem the completely opposite way. Instead of defaulting to doing
> what 1.3 does, you default to the opposite position. That is what I
> am saying is so wrong here. Pick the same default as 1.3, and allow
> the option to override that default.
Huh?! I *wanted* to get a 404 from the httpd. Did you really read my
posting?
There was introduced a bug, nothing more.
What I'm doing now *is* to allow to use the same config for 1.3.9 and 2.0
and 2.1.
> > > 2) In choosing to default to the 404, you have broken anybody who
> > > wants to share 1.3 and 2.0 config snippets.
No, see above.
> > Additionally 1.3 and 2.0 *are* different, so this is null argument at
> > all.
>
> I'm sorry, but no it is not. I know something about this, and we
> spent a lot of time and energy trying to ensure that a config that
> worked in 1.3 worked the same way in 2.0.
Well, you had no luck, it seems.
nd
Re: mod_actions 1.32 patch never made it to 2.0
Posted by Ryan Bloom <rb...@gmail.com>.
On Tue, 14 Dec 2004 17:13:23 +0100, André Malo <nd...@apache.org> wrote:
> * Ryan Bloom <rb...@gmail.com> wrote:
>
> > I have a couple of pretty big issues with this response.
> >
> > 1) You have a configuration in Apache 1.3 that doesn't work in Apache
> > 2.0, but the config directives don't have to be changed at all. This
> > is something that we worked really hard not to do in 2.0. There
> > should never be a config in 1.3 that just gives the wrong results in
> > 2.0 without any way for the user to understand why.
>
> Ah? That's what one would call a bug. While breaking the behaviour in
> 1.3.9/1.3.10 nobody even thought about this issue. It's *still not
> documented that it was broken*. And a lot of users suffered of it, including
> me.
Suffered how? How exactly did a change that made the code accept more
configs break your config? Also, it isn't that nobody thought of this
when making the change to 1.3. Looking through the mailing list
archives, I see Ben Laurie specifically had a problem with Location
and mod_actions that Manoj fixed. I haven't found the whole thread
about the problem, just the RM notes about it. So, we have a bug that
was fixed in 1.3 that was reintroduced in 2.0, and 2.0 is solving the
problem the completely opposite way. Instead of defaulting to doing
what 1.3 does, you default to the opposite position. That is what I
am saying is so wrong here. Pick the same default as 1.3, and allow
the option to override that default.
>
> > 2) In choosing to default to the 404, you have broken anybody who
> > wants to share 1.3 and 2.0 config snippets.
>
> [...]
> see above.
> Additionally 1.3 and 2.0 *are* different, so this is null argument at all.
I'm sorry, but no it is not. I know something about this, and we
spent a lot of time and energy trying to ensure that a config that
worked in 1.3 worked the same way in 2.0. We jumped through hoops to
ensure that a handler configured as it would be in 1.3 would work even
if the handler was moved to a filter. There should not be any
examples of a config directive that has the exact same syntax in 1.3
and 2.0 and different behavior. That is what we are talking about
here. The directive has the _same_ syntax in the two trees, thus it
should act the same way.
> > 4) This isn't documented anywhere at all. If you are going to break
> > old configs, then please add some docs to the docs-2.0 tree.
>
> Sure. It's not incorporated yet. It was voted recently and I'm going to
> commit it soon.
And I'm asking that you reconsider doing that so that 2.0 and 1.3 can
interoperate more cleanly. You aren't going to change how 1.3 handles
this situation, and 2.1 hasn't been released, and the change hasn't
been back-ported to 2.0. So, the 2.x tree should do what 1.3 does,
and your flag should allow you to override.
Ryan
--
Ryan Bloom
rbb@apache.org
rbb@redhat.com
rbloom@gmail.com
Re: mod_actions 1.32 patch never made it to 2.0
Posted by André Malo <nd...@apache.org>.
* Cliff Woolley wrote:
> So why is this same general behavior unconditional in httpd 1.3 but
> non-existant in 2.0 and requires a "virtual" flag on 2.1? Andre?
> Thoughts? The "virtual" thing was your doing...
see STATUS file. It's already voted for backport, just didn't make it yet...
The reason for the virtual flag is that it should be a user decision whether
the httpd should generate the 404 (with errordocument and all) or not. IMHO
the unconditional behaviour in 1.3 was a mistake (made in version 1.3.10).
2.x was forked in 1.3.9 :-)
nd
--
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook! Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook? Ook. Ook! Ook! Ook? Ook! Ook. Ook? Ook. Ook.
Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook! Ook! Ook! Ook! Ook.
Re: mod_actions 1.32 patch never made it to 2.0
Posted by Cliff Woolley <jw...@virginia.edu>.
On Mon, 13 Dec 2004, Ryan Bloom wrote:
> A co-worker of mine pointed out that the following works in Apache
> 1.3, but not 2.0 if the location /foo, doesn't exist on the disk:
>
> AddHandler foobar /cgi-bin/printenv
> <Location /foo>
> SetHandler foobar
> </Location>
>
> This patch ports this behavior forward into 2.0.
r1.32 of mod_actions in the httpd-2.0 CVS module is a 2.1.x revision
number. It adds a "virtual" option to the Action directive, "which allows
the use of handlers for virtual locations" (according to the commit log),
which I think does match up with what you're asking for here. But then
why this patch instead of backporting r1.32 to the 2.0.x branch? Is there
a revision number for similar behavior in apache 1.3? Oh, I see... that
would be r1.33 of mod_actions in the apache-1.3 CVS module. That does
indeed match up with your patch.
So why is this same general behavior unconditional in httpd 1.3 but
non-existant in 2.0 and requires a "virtual" flag on 2.1? Andre?
Thoughts? The "virtual" thing was your doing...
--Cliff