Re: complaint about CGI

Rob McCool (
Fri, 25 Feb 1994 11:49:15 --100

* 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?)