Re: Current status...

[Randy Terbush <ra...@zyzzyva.com>]

> Ben wrote:
> >On the subject of 2), although trapping self-inclusion is a good idea, I
> >wonder about the semantics. Seems to me that /a/b/some-ssi/extra/bits is
> >morally equivalent to /a/b/some-ssi?extra/bits, and the relative should
> >therefore be relative to /a/b/some-ssi. Or shouldn't it? I've heard the
> >"breaking existing sites" argument, and I have sympathy - we should make it
> >flaggable, as in "SupportBrokenExtraPathBehaviour on", but I do not approve of
> >the concept of perpetuating broken behaviour any more than is absolutely
> >necessary, and certainly not to the exclusion of correct behaviour. It seems
> >obvious to me that a relative path means "relative to me", not "relative to
> >whatever path happened to invoke me".
> 
> However, if you use 'relative to me' then relative paths parsed on the
> server will resolve differently to relative paths resolved by the client.
> i.e.
> <!--#include virtual="../xxx" -->
> and
> <A HREF="../xxx">
> 
> might point to different objects.
> 
> It would be better to forbid extra data on the URL to a SSI document, but
> we can't do that for compatibility reasons. However, this seems as good
> a reason as any to drop SSI in favour of a newly designed server-parsed
> implementation.
> 
>  David.

Dropping SSI would not create an incompatibility?

The compatibility that of the behaviour that exists...did it exist
in NCSA?  Didn't we decide it was a bug/feature?