> > The reason I want it is that having put something up as a file, or
> > collection of files, I may want to turn it into a script, without having to
...
> I know you have alreadly expressed a distaste for the redirection
> mechanism in HTTP/1.0, but this situation is exactly what it is
You can use redirection for this but it's a really bad idea (talk about
spaghetti code). Redirection is nice as the return from a query (esp.
spatial queries via ISMAP). Permanent redirections are supposed to be
automatically handled (client notifies server that it's URL is out of
date) but doing this right is a lot of work and it looks to be fairly low
on the prio list.
> > Like it or not, most of the existing servers already have such a mechanism
> > --- to tell what type a file is (in order to report the proper MIME type),
> > they discriminate on the basis of the name. If you put a GIF file up under
> > the name 'foo.au', or even just plain 'foo', then (with the stock NCSA
> > server, and Plexus and CERN as well, I believe), the wrong MIME type will
> > be reported back to the client, and things fall apart.
Of course, the servers do this because it's convenient.
Someday I will fix Plexus so this is done "right" and the typing isn't
wholy suffix dependent. I will probably end up keeping cache files
in each directory that get updated automatically as needed. There is
also the non-trivial issue of how to admin such a beast.
> If typing files by suffix were adequate there would be no point in
> using the MIME type at all, the client could just look at the
> suffix. In HTTP/0.9 file types were determined by suffix and there was
> no MIME type.
HTTP/0.9 clearly defined that ONLY plain text and HTML were valid return
types. NCSA Mosaic violated the spec and used the file suffixes, I'm not
saying this was an unreasonable thing to do, just making it clear that
HTTP never sanctioned this activity.
Basically, typing by suffix is UNACCEPTABLE for the client end (though as
NCSA Mosaic proved it can work ok for some stuff, that isn't the issue)
but it's perfectly fine for the server to use this if it wants. The key
is that there is nothing requiring the server to do so, it's mearly done
as a matter of convenience on some OS's.
> It is a bad idea to do so, but surely it should be *possible* with any
> HTTP/1.0 server to put up a GIF file with the name foo.au and have it
It is indeed possible and does work.
> work perfectly. BTW, the reason it is a bad idea is precisely the
> same reason it is a bad idea to have PATH_INFO data look like part of
> the path -- it is misleading and obscure.
I fail to see how:
http://server/path/cmd;args
Is really any clearer or better than:
http://server/path/cmd/args
The `;' scheme simply has too many drawbacks (namely you can't front-end
existing directory hierarchies with scripts).
Previously John said in <9312282330.AA05364@hopf.math.nwu.edu>:
> an arbitrary path and an arbitrary name. You must either have a magic
> directory name like "cgi-bin" in the path above the script or the
> script must have a name ending in a special suffix like ".doit". On
As others have pointed out, the server is free to use any out-of-band
information it needs/wants to decide what to do. Encoding this information
in the URL is generally regarded as a bad idea for the general case.
Using the execute bit, where available, is probably the best plan.
--sanders