Mailing List Archive

Last time, Robert S. Thau uttered the following other thing:
>
> From: Rob Hartill <hartill@ooo.lanl.gov>
> Date: Mon, 19 Jun 95 8:50:19 MDT
>
> Rob proposes the following...
>
> Given a URL, say x/y/z/foo.html, after Apache finds its way to the
> directory x/y/z/, it looks for a special map file, x/y/z/files.map which
> could contain things like
>
> foo.html/foo.shtml ( '/' is the onle safe char to use)
> logo.gif/logo
> index.html/index.asis
>
> ..so that before Apache goes any futher, it does a mapping on the filename.
> In the example above, my 'foo.html' is changed to 'foo.shtml' so that it
> can have includes. 'logo.gif' is changed to 'logo' so that multiviews or
> content-neg can pick the best type. 'index.html' becomes an '.asis' so it
> can redirect somewhere else.
>
> It seems simpler to just put the content-type in the map file,
> with the MIME type in the map file, if present, overriding the one
> which would be deduced from name suffixes. WN users seem to like it ;-).
>
> Of course, WN takes the whole scheme one step farther, by refusing to
> serve any file which *isn't* in the map file for the directory.
> Incidentally, the two obvious things to use as a syntax for these
> files are either the WN syntax, or perhaps the current Apache map file
> syntax --- NB the WN syntax has more users at this point.

Or, maybe not (though this is obviously incomplete):
Our crawler has found about 220 apache servers, and about 26 WN servers.

Of course, that doesn't mean all of the apache servers are using the
map files, while all of the WN servers are.

I'm sorry to say that NCSA 1.1 comes out over Apache at 315 sites.
*sigh*

Brandon



--
Brandon Long (N9WUC) "I think, therefore, I am confused." -- RAW
Computer Engineering Run Linux '95. It's that Easy.
University of Illinois blong@uiuc.edu http://www.uiuc.edu/ph/www/blong
Don't worry, these aren't even my views.

On Mon, 19 Jun 1995, Brandon Long wrote:
> Or, maybe not (though this is obviously incomplete):
> Our crawler has found about 220 apache servers, and about 26 WN servers.
>
> Of course, that doesn't mean all of the apache servers are using the
> map files, while all of the WN servers are.
>
> I'm sorry to say that NCSA 1.1 comes out over Apache at 315 sites.
> *sigh*

Ha! Sounds like "battle of the network superservers" :)

"Hi, we notice you're running an old, insecure version of <insert server
here>. Would you like to upgrade? Please click *here*"

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Sounds simple, but doesn't that require reading and parsing "files.map"
for every response? Even with everything cached, it sounds like a
strain. Why is having the link point to a basename and doing globbing on
file extension less elegant?

Brian


On Mon, 19 Jun 1995, Rob Hartill wrote:
> An idea for XBITHACK and more...
> You might remember me suggesting that Apache could replace XBITHACK
> by looking for .shtml when a .html wasn't found, well here's what I
> think is a better solution, and one which will probably have some other
> really useful applications..
>
> Given a URL, say x/y/z/foo.html, after Apache finds its way to the
> directory x/y/z/, it looks for a special map file, x/y/z/files.map which
> could contain things like
>
> foo.html/foo.shtml ( '/' is the onle safe char to use)
> logo.gif/logo
> index.html/index.asis
>
>
> ..so that before Apache goes any futher, it does a mapping on the filename.
> In the example above, my 'foo.html' is changed to 'foo.shtml' so that it
> can have includes. 'logo.gif' is changed to 'logo' so that multiviews or
> content-neg can pick the best type. 'index.html' becomes an '.asis' so it
> can redirect somewhere else.
>
> Simple, but very powerful me thinks.
>
> --
> Rob Hartill
> http://nqcd.lanl.gov/~hartill/
>

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

On Mon, 19 Jun 1995, Rob Hartill wrote:
> > Sounds simple, but doesn't that require reading and parsing "files.map"
> > for every response? Even with everything cached, it sounds like a
> > strain. Why is having the link point to a basename and doing globbing on
> > file extension less elegant?
>
> if you mean changing my links from foo.html to foo, then that can
> be part of the plan, however, there are potentially thousands of links
> from other sites all pointing at foo.html
> If all I have is a foo.shtml file, then a request for foo.html will
> return a 'not found' response... which isn't much good here.

Agreed... the "if file.html isn't found, try file.shtml" hack is starting
to look nicer these days.

If we were in the let's-take-a-larger-view mood, I might opine that the
real problem is the lack of being able to attach meta-information to a
file/directory external to that file/directory. This is something that
WN handles really well, and I remember hearing about a ".meta" file type
in CERN, but is lacking in the NCSA/Apache/Netsite model. Many parts of
our model deal with it - .asis files, .htaccess files, etc - but
something more unified and straightforward would be nice. Even if it
meant an extra file parse per access, as a "files.map" would. This way,
if the meta-info file had "Content-type: text/x-server-parsed-html" in
it, the server could parse it for includes.

Perhaps another way to accomplish this given the current framework woudld
be to have apache parse .asis files for Content-type and then act upon
them if it sees any magic mime types. Would sort of hurt the efficiency
of asis files, but since that's the cleanest way we have of attaching
metainfo right now anyways.....

Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

On Mon, 19 Jun 1995, Rob Hartill wrote:
> > Perhaps another way to accomplish this given the current framework woudld
> > be to have apache parse .asis files for Content-type and then act upon
> > them if it sees any magic mime types. Would sort of hurt the efficiency
> > of asis files, but since that's the cleanest way we have of attaching
> > metainfo right now anyways.....
>
> but that doens't solve the problem I was trying to address, that of
> wanting to change the type of an existing URL.
>
> foo.html is well established, so I can't have a foo.asis for it.

Ah, but you could have a "foo.html.asis". :)

> A map file would let me say, "foo.html" is obsolete, use "foo.asis"
> instead, but the real beauty of all this for us with Apache, is that
> we can say, "foo.html" is obsolete, use "foo" instead.. and let the
> multiviews/cn do the dirty work of picking the appropriate file. This
> would let everyone migrate to content-type-free URLs, while still
> supporting the old external links, and the migration would be transparent
> and painless to everyone.

Let's just change the "not found" rule, so that if a file "foo.html"
isn't found, it tries "foo.map", and if that isn't found *and*
multiviews is turned on, it looks for "foo", doing globbing as needed.
If you happened to have a "foo.gif", well, you're asking for it :)

> In terms of XBITHACK, the map file would have a list of well established
> .html (+x bit) filenames which no longer exist, and ideally, they'd
> map to extensionless filenames, which multiviews would use to pick a
> .shtml file, which apache would parse. One could also have a .shtml+
> to parse the HTML and send a last_modified too.

I'd like to make filenames as opaque as possible, really. Either that or
have a formal (internal to apache) specification for them, so that file
names could be used to express other meta-information as well.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

>
>
> Sounds simple, but doesn't that require reading and parsing "files.map"
> for every response? Even with everything cached, it sounds like a
> strain. Why is having the link point to a basename and doing globbing on
> file extension less elegant?

if you mean changing my links from foo.html to foo, then that can
be part of the plan, however, there are potentially thousands of links
from other sites all pointing at foo.html
If all I have is a foo.shtml file, then a request for foo.html will
return a 'not found' response... which isn't much good here.

What I was proposing was something like a redirect within a directory.
Redirecting out of the directory has lots of relative URL problems, so
the map file would have to be from file to file in the same dir.

rob
--
http://nqcd.lanl.gov/~hartill/

From: Rob Hartill <hartill@ooo.lanl.gov>
Date: Mon, 19 Jun 95 8:50:19 MDT

Rob proposes the following...

Given a URL, say x/y/z/foo.html, after Apache finds its way to the
directory x/y/z/, it looks for a special map file, x/y/z/files.map which
could contain things like

foo.html/foo.shtml ( '/' is the onle safe char to use)
logo.gif/logo
index.html/index.asis

..so that before Apache goes any futher, it does a mapping on the filename.
In the example above, my 'foo.html' is changed to 'foo.shtml' so that it
can have includes. 'logo.gif' is changed to 'logo' so that multiviews or
content-neg can pick the best type. 'index.html' becomes an '.asis' so it
can redirect somewhere else.

It seems simpler to just put the content-type in the map file,
with the MIME type in the map file, if present, overriding the one
which would be deduced from name suffixes. WN users seem to like it ;-).

Of course, WN takes the whole scheme one step farther, by refusing to
serve any file which *isn't* in the map file for the directory.
Incidentally, the two obvious things to use as a syntax for these
files are either the WN syntax, or perhaps the current Apache map file
syntax --- NB the WN syntax has more users at this point.

(On the other hand, some people might not like the scheme, or might
have trouble dealing with the overhead of checking for the cache
files; they might want to leave the feature off --- or better yet,
leave it out. This is one of the things that I've tried to do with
Shambhala; it *should* be possible to link a WN-compatibility module,
and have it interact correctly with the rest of the server, including
directory indexing (icons corresponding to listed content-types, even
if they differ from the suffixes), etc., though it's probable that
anyone who tried that in a current release would turn up a few
glitches that would need to be fixed before it really worked. Then
people who wanted it could have it, and people who didn't wouldn't
even need to have the code in their server).

rst

>
> Perhaps another way to accomplish this given the current framework woudld
> be to have apache parse .asis files for Content-type and then act upon
> them if it sees any magic mime types. Would sort of hurt the efficiency
> of asis files, but since that's the cleanest way we have of attaching
> metainfo right now anyways.....

but that doens't solve the problem I was trying to address, that of
wanting to change the type of an existing URL.

foo.html is well established, so I can't have a foo.asis for it.
A map file would let me say, "foo.html" is obsolete, use "foo.asis"
instead, but the real beauty of all this for us with Apache, is that
we can say, "foo.html" is obsolete, use "foo" instead.. and let the
multiviews/cn do the dirty work of picking the appropriate file. This
would let everyone migrate to content-type-free URLs, while still
supporting the old external links, and the migration would be transparent
and painless to everyone.

In terms of XBITHACK, the map file would have a list of well established
.html (+x bit) filenames which no longer exist, and ideally, they'd
map to extensionless filenames, which multiviews would use to pick a
.shtml file, which apache would parse. One could also have a .shtml+
to parse the HTML and send a last_modified too.



rob
--
http://nqcd.lanl.gov/~hartill/

Let's just change the "not found" rule, so that if a file "foo.html"
isn't found, it tries "foo.map", and if that isn't found *and*
multiviews is turned on, it looks for "foo", doing globbing as needed.
If you happened to have a "foo.gif", well, you're asking for it :)

Actually, it nearly does that --- if you request "foo", and MultiViews
finds "foo.map", that gets used instead of the map which MultiViews
would otherwise have built internally. All you'd have to do is fix
MultiViews so that it tried stripping the suffix...

rst

> Let's just change the "not found" rule, so that if a file "foo.html"
> isn't found, it tries "foo.map", and if that isn't found *and*
> multiviews is turned on, it looks for "foo", doing globbing as needed.
> If you happened to have a "foo.gif", well, you're asking for it :)

(ding) Yes. I like this. I have also felt the the proposed
filename/meta info hack was the way to go for several other issues
proposed in the past.

> I'd like to make filenames as opaque as possible, really. Either that or
> have a formal (internal to apache) specification for them, so that file
> names could be used to express other meta-information as well.
>
> Brian

(oops.. more coffee)

I also wanted to add to that last Email that I strongly discourage
the use of the WN/GN model. I had to deal with these .cache files
in my micro-novice days (couple of months ago) and quickly ditched
GN in favor of a more managable approach.

From: Randy Terbush <randy@zyzzyva.com>
Reply-To: new-httpd@hyperreal.com

I also wanted to add to that last Email that I strongly discourage
the use of the WN/GN model. I had to deal with these .cache files
in my micro-novice days (couple of months ago) and quickly ditched
GN in favor of a more managable approach.

It always looked to me like being *far* more trouble than it's worth,
but a lot of people in the Gopher world swear by it, even going so far
to say how unmanageable it is to put stuff up on a Web server than it
is on a Gopher server because the web servers don't support all that
crud.

(I've always assumed that what's really going on is that these people
have a massive investment in scripts to maintain and generate menu and
cache files, and don't want to either ditch it all, or rewrite it from
nearly scratch to generate HTML <ul>s instead of the menu files. But,
de gustibus).

rst