Mailing List Archive

Redirect problem
My guess is that shambhala is processing ScriptAlias before
Redirect, because we have,

Redirect /htbin/ http://arachnid.cm.cf.ac.uk/htbin/
ScriptAlias /htbin/ /mnt60/apache/htbin/


/htbin/ used to be serviced by this machine, but was Redirected
to another (arachnid) recently.

Apache acts on the Redirect before expanding the ScriptAlias.
Same is probably true for Alias.

We'll need to make this Apache/NCSA compatible.


rob
--
http://nqcd.lanl.gov/~hartill/
Re: Redirect problem [ In reply to ]
Isn't this a matter of parsing order? I.e., is shambala expanding *all*
ScriptAlias directives before Redirects, or is it simply the case that
because the ScriptAlias came after the Redirect for the same resource,
the latter had precedence?

Brian

> From: Paul Richards <paul@netcraft.co.uk>
> Subject: Re: Redirect problem
> To: new-httpd@hyperreal.com
> Date: Tue, 11 Jul 1995 20:49:08 +0100 (BST)
>
> In reply to Rob Hartill who said
> >
> >
> > My guess is that shambhala is processing ScriptAlias before
> > Redirect, because we have,
> >
> > Redirect /htbin/ http://arachnid.cm.cf.ac.uk/htbin/
> > ScriptAlias /htbin/ /mnt60/apache/htbin/
> >
> >
> > /htbin/ used to be serviced by this machine, but was Redirected
> > to another (arachnid) recently.
> >
> > Apache acts on the Redirect before expanding the ScriptAlias.
> > Same is probably true for Alias.
> >
> > We'll need to make this Apache/NCSA compatible.
>
> A more correct approach would be to issue an error for ambiguous
> declarations.
>
> Things will (already are) get messy if internal behaviour of the
> server is relied upon to arbitrate in situations like this since
> you become tied to old behaviour and much worse, changes to the
> server that you wouldn't expect to cause problems have unexpected
> results, as we're seeing here..
>
> It would be better to bite the bullet now and lay down the law as to what
> is correct rather than perpetuate bad practices.
>
> Simply aborting at startup clearly stating an ambiguity has been found in
> the configuration files has been found would be more of a favour to
> web admins.
>
> I wouldn't put NCSA compatibilty too high on the list. What will make
> people switch to Apache is the fact that it's doing things right.
>
>
> --
> Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
> Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
> Phone: 0370 462071 (Mobile), +44 1222 457651 (home)
>
>

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: Redirect problem [ In reply to ]
In reply to Brian Behlendorf who said
>
>
> Isn't this a matter of parsing order? I.e., is shambala expanding *all*
> ScriptAlias directives before Redirects, or is it simply the case that
> because the ScriptAlias came after the Redirect for the same resource,
> the latter had precedence?

Hmm, needs some thought this since I can see merit in a number of
different ways to go.

1) Parse all redirects first
-- Gets the client off your server asap.
2) Parse aliases first, you can have a redirect for a particalar
page and any other pages that are aliased to that area will follow
the redirect.
3) Parse them in the order they occur in the config file, gives the
admin free reign.

Disadvantages:

1, and 2 need more intelligent parsers that scan the whole file
before doing anything.

3, needs the sanity checks I mentioned in my previous mail.

Re-writing the parser is a good idea, there are lots of things we can
check and warn about (or even fix) at startup if we had an overview
of the complete configuration, rather than dealing with it line
by line.

I'll even volunteer to write a new parser and sort out a decent config
language while I'm at it. We can leave the old parser code there for now and
select which parser to use from looking at the configuration files and
determining which one to use. That would allow us to maintain backward
compatibilty with NSCA config files but develop our own layout and
format in parallel. Easy to do, just need to find the time :-)

--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)
Re: Redirect problem [ In reply to ]
In reply to Robert S. Thau who said
>
> Hmmm... this is difficult in a Shambhala-style modular framework
> because there cannot be a single configuration data structure which
> can be consistency-checked as a whole --- instead, there are a group
> of modules, each of which does translation on certain URIs, and the
> user is free to add more at any time. (This is the whole point of
> having an API in the first place).

Not that hard to solve. If the configuration syntax is suitable you
load in the module when the parser detects that one's needed. The
assumes we have some form of dld available though.

>
> In fact, even with the standard module set, filename translation is
> split between three different modules --- the CGI module handles
> ScriptAlias, while the alias module handles plain Alias (and
> Redirect), and the UserDir module handles /~ stuff.

I'm not sure the module segregation is the most appropriate. I've
just grabbed shambala 6.0 so I'll gradually work my way through the
code....


--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)
Re: Redirect problem [ In reply to ]
In reply to Rob Hartill who said
>
>
> The problem is only with the order in which Redirect/Alias/ScriptAlias
> are *acted* upon. The order of the entires in the config file(s) has
> no bearing on this problem.

Well, if we decide we want the config order to determine priority then
parsing does have a bearing on this.

>
> In the above, (1) is easy to do; 0.6.5 does it.
>
> Redirects are mostly used to map established URLs to other servers, so
> one needs to tolerate superfluous ScriptAlaias and Alias entries,
> n.b. the redirect might be temporary. Removing the Redirect should be enough
> to restore old behaviour.

There's still a case for doing the aliases first so that if you redirect
a page, any aliases you have pointed to it will get redirected too.

This is one of those areas where compatibilty is a problem since
I think there's good reason to sit down and decide what the correct
way to do this is but that wil almost certainly break some
configurations, just like it broke Cardiff's.

--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)
Re: Redirect problem [ In reply to ]
Brian Behlendorf said

> Isn't this a matter of parsing order? I.e., is shambala expanding *all*
> ScriptAlias directives before Redirects, or is it simply the case that
> because the ScriptAlias came after the Redirect for the same resource,
> the latter had precedence?


Paul Richards responded

> Hmm, needs some thought this since I can see merit in a number of
> different ways to go.
>
> 1) Parse all redirects first
> -- Gets the client off your server asap.
> 2) Parse aliases first, you can have a redirect for a particalar
> page and any other pages that are aliased to that area will follow
> the redirect.
> 3) Parse them in the order they occur in the config file, gives the
> admin free reign.

The problem is only with the order in which Redirect/Alias/ScriptAlias
are *acted* upon. The order of the entires in the config file(s) has
no bearing on this problem.

In the above, (1) is easy to do; 0.6.5 does it.

Redirects are mostly used to map established URLs to other servers, so
one needs to tolerate superfluous ScriptAlaias and Alias entries,
n.b. the redirect might be temporary. Removing the Redirect should be enough
to restore old behaviour.


rob
--
http://nqcd.lanl.gov/~hartill/
Re: Redirect problem [ In reply to ]
> Well, if we decide we want the config order to determine priority then
**
> parsing does have a bearing on this.

I've no problem with the *if*, I thought we were talking about
how to get Shambhala to behave like 0.6.5

> There's still a case for doing the aliases first so that if you redirect
> a page, any aliases you have pointed to it will get redirected too.

Alias maps URLs to filenames.
Redirect works on URLs

at least that's the way they do now.

> This is one of those areas where compatibilty is a problem since
> I think there's good reason to sit down and decide what the correct
> way to do this is but that wil almost certainly break some
> configurations, just like it broke Cardiff's.

It'd mean splitting config processing into old/new styles. As with
my attempt to get AddType "."s handled sensibly, "the correct way"
appears to be chissled into stone as "whatever 0.6.5 does now".

rob
--
http://nqcd.lanl.gov/~hartill/
Re: Redirect problem [ In reply to ]
From: Paul Richards <paul@netcraft.co.uk>
Date: Wed, 12 Jul 1995 11:58:57 +0100 (BST)

I'll even volunteer to write a new parser and sort out a decent config
language while I'm at it. We can leave the old parser code there for now and
select which parser to use from looking at the configuration files and
determining which one to use. That would allow us to maintain backward
compatibilty with NSCA config files but develop our own layout and
format in parallel. Easy to do, just need to find the time :-)

Hmmm... this is difficult in a Shambhala-style modular framework
because there cannot be a single configuration data structure which
can be consistency-checked as a whole --- instead, there are a group
of modules, each of which does translation on certain URIs, and the
user is free to add more at any time. (This is the whole point of
having an API in the first place).

In fact, even with the standard module set, filename translation is
split between three different modules --- the CGI module handles
ScriptAlias, while the alias module handles plain Alias (and
Redirect), and the UserDir module handles /~ stuff.

(BTW, the Shambhala config code already is a total rewrite, and it is
pickier about certain forms of syntax errors than the original, as
some people who have tried it have already discovered).

rst