Re: complaint about CGI

robm@ncsa.uiuc.edu (Rob McCool)
Errors-To: listmaster@www0.cern.ch
Date: Fri, 25 Feb 1994 11:49:15 --100
Message-id: <9402202309.AA10155@void.ncsa.uiuc.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: robm@ncsa.uiuc.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: robm@ncsa.uiuc.edu (Rob McCool)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: complaint about CGI
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2664

/*
 * Re: complaint about CGI  by John Franks
 *    written on Feb 20,  3:07pm.
 *
 * According to Ari Luotonen:
 * > > The question is, what do we do about it? Many people want me to ``fix''
 * > > httpd so that it sends any unknown headers back to the client. This 
 * > > isn't so bad, and would be backward compatible, but I don't 
 * > > want people to depend on it without formally changing the spec
 * > 
 * > I'm all for it.
 * 
 * I am happy with either way as long as we have a clear cut spec that is
 * well publicized. It is not enough for us to agree among ourselves or
 * agree on www-talk. If we agree to change, someone (presumably Rob) has
 * to document the changes.  I think it is unacceptable if people have to
 * look at the source code of a server to understand the spec.

I agree here. One of the things which is a source of endless frustration for
me is the fact that three quarters of the HTTP spec is TBS and things seem
to change without much notice (Location->Uri).

 * > > (John, Ari, what did you guys do?).
 * > 
 * > Originally I sent back all the headers, but took that off since the
 * > spec marked this as illegal.
 * 
 * I followed the spec and take only Content-type from the script.

Okay, then the question is, do we change the spec, or encourage nph- as the
viable alternative? If we change the spec, should we make it CGI/1.1 so that
the script knows that the server will accept its headers?

 * > BTW, Rob: Content-Encoding should be Content-Transfer-Encoding :-(
 * 
 * I agree with this!  But it isn't only Rob's problem. I originally used
 * Content-Transfer-Encoding until I found that Mosaic won't accept that,
 * only Content-encoding.  I am also still campaigning for browsers which
 * handle decoding to announce that fact in an Accept-Encoding (or
 * whatever the correct name is) header.  Gif and au files may be pretty
 * well compressed already but for Postscript files, for example,
 * compression is a *big* win.  Postscript is likely to be a standard way
 * to distribute math journal articles and it would be very nice to
 * compress on the fly if the browser can handle it (or decompress if it
 * can't).
 */

Thus said the HTTP spec:

> Content-Transfer-Encoding

> As in MIME. Some profiling and/or extension may be necessary, TBS.
> (Compression is not treated as transfer encoding by MIME). 

said the HTTP spec.

As I recall, the compression encoding we implemented in Mosaic and httpd was
based on a proposal bouncing back and forth between Marc, Tony, and I. I
don't know how much basis in MIME it had (if MIME doesn't use
Content-transfer-encoding for compression, then what does it use?)

--Rob