> As I reported earlier, if I want to see a gziped HTML file, it is > first downloaded to the local filesystem, then shown (using builtin > gzip stream support). I would expect the builtin gzip stream support > be applied directly to the stream coming from the socket.
This area has given me trouble. It's closely aligned with the mime determination of the file type. Some extensions are hard coded, others are read in via mailcap:mime.types files and/or VIEWER:SUFFIX definitions. It is _conceivable_ that someone might want to view html with something other than Lynx -- or Lynx but with a different configuration. With the present scheme, that can be done. If you parsed it directly from the uncompressed stream, you'd be locked into Lynx as presently configured. What has happened to me is somewhat the opposite: Lynx will uncompress a binary file and then present it as if it were text. Recently that happened with one of those macintosh hex (bin?) files. I suppose because mac files generally don't ship with an extension? Tom's rushing to get a release out, but maybe I can tack this onto the wish list for the release after that. It would be nice if Lynx had code to autodetect binary. I think there are a number of open source routines which could be plugged in. I think it would make Tom's recent addition to the d)ownload options more meaningful, and could be used in various areas where compressed data is handled. (For example, wouldn't trip when the server's configuration is wrong.) __Henry (About the bzip2 support, there really isn't all that much of an advantage over just using an external. I find it a toss up between libz and gzip even now.) ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
