Re: URLs for trees.

Martijn Koster (m.koster@nexor.co.uk)
Thu, 15 Sep 1994 19:02:23 +0200

> If /hallam is not a simple directory then the script can chose to do
> what it likes. For smoe scripts it actually makes sense to allow
> such urls.

Yes, if a single script is responsible then it could decide. I was wondering
how a server is going to handle http://.../cgi-bin/*** for example; does
it give me my cgi-bin directory tree, or call all scripts?

> I don't want extra methods. They cannot be used without a new browser.

EHr, no, but you need a new browser to handle the multi-part messages
anyway, and as you said this isn't likely to be used directly by
browsers but by other applications. So I don't see why mehtods would
introduce a problem.

> I can ask the M-object to get url /hallam/* and it will do it.

Yes, but you are changing the way URL's are decoded in the Web --
I think this is likely to impact certain uses.

> There is a problem with the /** convention, how does it work with
>
> /*.html is all the files with a .html extension
>
> /**.html is what ?
>
> /m*.html is all files matching the pattern
> /**m*.html is what?
>
> or should we have /*/m*.html ? This seems to work better.

Exactly the sort of problems you get into with URLs.

> So this would mean changing the uri spec to state that /*/ indicated a
> recursive descent of directories.

Groan, just as they finalised the draft :-)

I suppose it depends how you think about this facility. Are we talking
about a "meta object" (URL), or about an operation (method)? As we're
talking about protocol here I think the latter is more appropriate.

> >Yeah, like robots and mirrors -- will people really allow this on
> >their servers, even if you recursively check modification dates
> >against an If-modified-since? I certainly won't without out of band
> >bilatreal agreement with clients.

> It would not be the sort of thing that you would want to have everyone doing
> but we have enough security schemes, access controls etc.

Sure.

-- Martijn
__________
Internet: m.koster@nexor.co.uk
X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M
X-500: c=GB@o=NEXOR Ltd@cn=Martijn Koster
WWW: http://web.nexor.co.uk/mak/mak.html