W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: Assigned paths

From: Hallam-Baker <hallam@ai.mit.edu>
Date: Mon, 30 Jun 1997 10:39:51 -0400 (EDT)
Message-Id: <199706301439.KAA23130@muesli.ai.mit.edu>
To: delabeau@iniki.gsfc.nasa.gov
Cc: GK@acm.org, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3595

> Either a prefix like /cgi-bin or suffix like .cgi may be relevant, depending
> on the server config.

In the context of 1.1 compliant servers cgi or otherwise plug in enabled
servers should by default be explicitly stating that the content is not

The heuristics whereby 1.0 proxies guessed what material was static and 
what was dynamic are legacy issues that we should not be carrying over.

There can be no assigned paths in HTTP that will not cause problems. Consider
a machine where the file system is served via HTTP rather than NFS. In this
context it would make perfect sense to access a file /foobar.com/cgi-bin/a.cgi
as a static file. 

"Assigned paths" sounds pretty much like what we used to call a "land mine".
Some arbitrary restriction embedded in a protocol that means that a whole
class of problems have to be considered a special case.

If people want a robot control protocol we should write the damn thing into 
the spec. Its quite an easy problem to solve because most of the Web crawling 
is done by the index compabies who are probably likely to play ball.

Received on Monday, 30 June 1997 07:41:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC