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