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: many URL per resource
Date Thu, 12 Oct 1995 11:56:20 GMT
> >> In fact, I don't know of anyone that does so.  
> > 
> > Ask in c.i.w.s.u  the problem comes up on a regular basis.
> 
> You mean the problem of how to pass parameters to a script called
> via an SSI include comes up regularly, right?  That is a separate
> problem and one that is not "solved" by inheriting it from the SSI path.

It isn't?

> >> Extra path is useful for ASIS files because
> >> they can be used to redirect or close-off an entire resource tree.
> > 
> > I'm trying to figure out how an ASIS file can do anything with 
> > path info. It's a static file to be sent "as is". How does it read
> > the PATH_INFO? - I'm not saying it can't, I'm saying I'm unaware of
> > a way in which it could.
> 
> It can't (at least that I know of).  I was thinking in terms of my "gone"
> CGI script to which I redirect people who have left UCI without a forwarding
> address for their home page.  For example,
> 
>     http://www.ics.uci.edu/~lsanchez/home.html
> 
> (or any URL that starts with /~lsanchez/) returns an error message
> which is more informative than 404 Not Found.  What matters is simply
> that any extra path info is ignored, and so I could replace it with
> an ASIS file.

That's a neat idea.  Which leaves me a little confused cuz it's analogous
to that example I gave about a u+x *.html file 'caring' about the path info,
and a 'u-x' *.html file not caring.

> >> Any server resource that uses extra path info is able to create a web
> >> black hole by ignoring (on purpose or not) the extra path and including
> >> relative path references in the returned entity.  
> > 
> > Isn't it just as likely that if someone were to write a recursive
> > link in a HTML file, it's just as likely they'd do the same via CGI.
> 
> No -- CGI programs tend to be better maintained than HTML files.
> There are also several orders of magnitude fewer CGI scripts than 
> HTML files, and clueless people are not allowed to install CGI scripts
> on our server.

These observations do not hold for any system that I've been on. ;)

> > Compared to some of the problems we've swept under the carpet, this
> > one doesn't strike me as being important.
> 
> I didn't say it was important.  It is just a bug.

It's not a bug IMHO.  I think we have different views on what functionality
a webserver might be able to provide - essentially we're disagreeing about
the interpretation of a URL, once it's inside the server.  Or perhaps we
aren't. Buh.

> The reason it hits
> me is because I've done research in the area of maintaining webs, and
> you can't find problems if your server lies about retrieval success.
> I have fixed some of these problems in HTTP/1.1, but there's nothing
> I can do about servers returning 200 when they are supposed to return
> 404 (or 410).

Well you could fix the server so that it records whatever additional
information you might require to assist in debugging:

193.131.203.66 - - [12/Oct/1995:10:55:09 +0100] "GET /includeif.html/glossary HTTP/1.0" 200
1024 [/glossary ignored]
193.131.203.66 - - [12/Oct/1995:10:55:10 +0100] "GET /~lsanchez/home.html HTTP/1.0" 200 521
[internal redirect to ASIS file '/home/www/ASIS/not_here.html', /home.html ignored]

> .....Roy

I'm arguing for arguing's sake.  If I need the functionality I can just
adopt or adapt a server to provide it.

Looking at this discussion a different way:

1)	-1 for Ben L's patch means that we get to keep this funky
	functionality which might only have crept under the net in the
	first place by our not converting from 0.6.5 properly.

	The drawback, as Roy F points out is that it can be difficult
	to trace access problems, because 'Not Found' files aren't
	being recorded in the access log.  This is because the server's
	semantics have changed, it no-longer regards:

		/foo.html/bar/baz

	as being nonsense if foo.html exists.

2)	+1 for Ben L's patch means that Roy can trace all his broken
	accesses again, and we keep the spirit of compatibility with
	0.6.5 [this last point is something I've always said was important
	in the past]

	The drawback is that anyone else who discovered the trick
	in the meantime is going to be screwed when they upgrade
	to 0.8.15/1.0, because suddenly they'll be back in 0.6.5-land
	again.

Now the killer...

I've got lots of servers on my dev box.

Apache	0.8.14	likes	http://foo/bar.html/ignore/this

	for u+x bar.html incorporating SSI, and for u-x bar.html
	and in both cases where '.../ignore/this' doesn't exist

Apache	0.6.4b	likes	http://foo/bar.html/ignore/this

	ditto...

NCSA	1.3R	hates	http://foo/bar.html/ignore/this

	Returns 403 Forbidden.

So, 0.8.14 isn't compatible with 1.3R in this respect, and Apache hasn't been
compatible since at least 0.6.4b.

Right now I'm torn between +1 and allowing Apache to remain incompatible and
useful for debuggers, or -1 and losing a new toy, and alienating anyone
who found the feature and began using it sometime between now and 0.6.4b.

Life can be hell sometimes... ;)

Ay.


Mime
View raw message