httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wilson <and...@tees.elsevier.co.uk>
Subject Re: Patch go boom...
Date Tue, 10 Oct 1995 15:37:26 GMT
> >I agree in essence; a URL is not a file. However, it seems to me that the
> >whole URL should be used to determine the content. Redundant extra bits
> >can be ignored, but it seems more sensible and useful to not ignore them.
> >Of course, in the case of SSI and CGI enforcing this is beyond the remit of
> >the server, but where plain ordinary files are concerned, the server can
> >see that there is extra meaningless stuff and should complain appropriately.
> >If there are some that think the old behaviour is useful, we can make it a
> >configurable flag.
> 
> Although it's not what you meant, the _old_ behaviour (apache 0.6.5 and
> earlier) was to reject /path/file.html/extra/data. We should default
> to compatibility unless someone has a convincing argument for changing the
> behaviour (i.e. a convincing argument for not fixing the bug).

Well ok.  I've been for a jog and had a think about it.  Ben L's patch
makes explicit an assumption that trailing information is meaningless and
indeed r0ng IFF the resource in question is a plain *.html, *.gif or whatever
file.  It doesn't effect SSI behaviour (sorry, my mistake, I misinterpreted
Ben's intent) and CGI is also unaffected.

This week we've seen a suggestion from Cameron Elliott <cam@indy.mvbms.com>
which uses in-URL cookies, essentially non-path information being passed to
the server alongside path information.  One way to implement this could be
to allow cookies embedded in trailing information to be accepted, but again
there'd be a smart module which could process this additional info out of the
URL before the default server behaviour kicked in and trashed the access.

Mmm...

I can think of one example (feasible, but arcane and an acre of pain to
implement) where Ben L's patch would hurt.  Suppose you wanted to provide
different content from the same file, depending on the nature of the PATH_INFO.

	[in this example I'll use #exec SSI calls, but clearly this might
	be better performed by a to-be-written conditional SSI module.

	eg:	<h2>Section 2</h2>
		<!--#if ( PATH_INFO eq expanded ) -->
			<blockquote>
			The section wherein we describe, in full, that which
			is to be described between the first and the third
			section.
			</blockquote>
		<!--#endif -->
		Blah, blah, blah...
	]

If a set of URLs were published:

	http://foo/bar/baz1.html/brief
	http://foo/bar/baz1.html/expanded
	http://foo/bar/baz1.html/glossary

	http://foo/bar/baz2.html/expanded
	http://foo/bar/baz3.html/glossary

	...

Then people would be able to put all the pertinent information in a single
file (which makes sense in terms of managing the data) and would be able to
offer different views of the data depending on the trailing information
they embed in the URL.  Ok, now suppose that Joe DataManager wanted to
switch this functionality off by 'chmod u-x'ing the file.  SSI would stop
working and only a reasonable subset of the full text would be exported to the
browser, regardless of the trailing information.

	[using SSI as it stands this might be done so:

	eg:	<h2>Section 2</h2>
		<!--#exec cmd="/home/andrew/bin/SSI/includeif \
			expanded \
			'<blockquote> 
			The section wherein we describe, in full, that which 
			is to be described between the first and the third 
			section. 
			</blockquote>'"
		-->
		Blah, blah, blah...

	Read the enclosed source for more info, try switching between u+x
	and u-x, or your local equivalent, on the .html file.
	]


...but, as has been pointed out before now.  I can always find a reason to NOT
do something.

>  David.

For the time being I'll close. I'd be nice if there was a note made in
the compatability issues section regarding this reaffirmation of 0.6.5's
behaviour?  Basically I'll probably be reversing the patch on my own gear.

Cheers,
Ay.


--- cut here ---

<html>
<head>
<title>includeif</title>
</head>
<body>
<h2 align=center>includeif</h2>
<blockquote>
	This is funky.  Try appending one of the following to the URL:
	<dl>
	<dt> <b>/expanded</b>
	<dd> More information than you can usefully manage at a glance.
	<dt> <b>/glossary</b>
	<dd> Just what do all those terms mean anyway.
	</dl>
</blockquote>
<h2>Section 2</h2>
<!--#exec cmd="/home/andrew/bin/SSI/includeif \
	expanded \
	'<blockquote> 
	The section wherein we describe, in full, that which 
	is to be described between the first and the third 
	section. 
	</blockquote>'"
-->
Blah, blah, blah...

<!--#exec cmd="/home/andrew/bin/SSI/includeif \
	glossary \
	'
	<h2>Glossary</h2>
	<dl compact> 
	<dt> <b>foo</b>
	<dd> That which is to be called <i>foo</i>.
	<dt> <b>bar</b>
	<dd> That which is not <i>foo</i> but is nonetheless <i>bar</i>.
	</dl>'"
-->

</body>
</html>


--- cut here ---

#!/usr/local/bin/perl

#	includeif
#
#	Andrew Wilson 10.Sep.95
#

( $IF, $WHAT ) = @ARGV;

if ( $ENV{PATH_INFO} eq "/$IF" ) {
	print "$WHAT";
};

exit;

--- cut here ---

Mime
View raw message