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.
Here are relevant info: http://math.berkeley.edu/~ilya/software/tmp/table_2col_bold_it_500000.html.gz Head shows: Content-Type: text/html; charset=ISO-8859-1 Content-Encoding: gzip Trace contains this fragment: HTMIME: Was CONTENT_, found E, checking for 'ncoding:' HTMIME: PICKED UP Content-Encoding: 'gzip' HTMIME: Extended MIME Content-Type is text/html;charset=iso-8859-1 HTMIME: MIME Content-Type is 'text/html', Treating as 'www/compressed'. Converting to 'www/present' HTFormat: Constructing stream stack for www/compressed to www/present HTFormat: Looking up presentation for www/compressed to www/present StreamStack: found weak wildcard match: www/present FindPresentation: found exact match: www/compressed StreamStack: found exact match: www/compressed LYOpenTemp(,.html.gz,wb) -> 'd:\tcpip\tmp\L32589-669TMP.html.gz' ... LYOpenTemp(d:\tcpip\tmp\L32589-669TMP.html.gz) Thanks for any insight, Ilya P.S. How hard is to modify the gzip support to have a builtin bzip2 support too? ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
