Re: many URL per resource

["Roy T. Fielding" <fi...@avron.ICS.UCI.EDU>]

>> 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.

>> 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.

>> 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.

> 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.  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).

.....Roy